Using Munki’s force_install_after_date key to force items to install

Keeping machines up to date can be a challenge. Munki tries to make this as seamless as possible, especially if you mark certain items as unattended installs (Munki will try to install those items in the background and not even bother the user).

But some updates require a logout or a reboot, and users generally don't like to log out or reboot often, particularly if they have laptops (as opposed to desktops). So pending updates can sit there for days, weeks, months, even over a year, unless you force the user to install the items.

I wouldn't recommend using the force_install_after_date option very often, but it can be very handy, particularly if there are critical updates that need to get to users.

And even though Munki itself will attempt to notify users of forced updates, you may want to accompany those built-in warnings with warnings of your own (via email, in person, etc.).

At the final countdown, the screenshots below are examples of what your users will see. Every time there's an OK button in the Managed Software Center, your user has the option to close Managed Software Center for a short time, but then MSC will just pop back up again soon. At the very last dialogue, the user will have no choice but to install the pending install item.

Once again, use sparingly, but you may need to use it, so it's good to know roughly what your users will see...

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

Using Reposado to manage cached Mac updates

Usually if you get Mac updates, those updates come straight from Apple's servers. If you have the caching service enabled on OS X Server, the updates will cache there every time a new one is requested from a client, and then future clients requesting the same update will download from the caching service instead of from Apple's servers directly.

Reposado allows you to, in addition to caching updates, create "branches" for testing and production (and development, if you want to make the distinctions that fine) so you can test updates before making them available to all your Mac clients. Keep in mind, though, Reposado works for Mac clients. It does not, unlike OS X Server's caching service, cache iOS updates or purchases.

Lots of good documentation on how to install and use Reposado already exists, so I won't rehash all that.

The only thing I couldn't find in the default functionality was some kind of auto-promotion from a testing to a production branch, so I wrote one: ReposadoAutopromote. After a few days (number of your choosing), anything in the testing branch will automatically move up to the production branch (name of the branches also your choosing). This gives you some time to test updates before rolling them out to clients, but then you don't have to examine each and every individual update and move them all over—you get some time to get a troublesome update out of testing before the auto-promotion happens.

Making Microsoft AutoUpdate check manually for Macs with Munki

Note: I'm writing with regard to Microsoft Office for 2011. It's possible the .plist file updates here is different for other versions of Microsoft Office for Mac.

If you're using Munki to manage software updates, you don't want the applications themselves to be constantly checking for updates or notifying your users when an update is available. Just as you can disable Java update prompts and disable Adobe Flash player prompts, you can also disable Microsoft Office update prompts.

To do so from the GUI (graphical user interface), you open up an MS Office application like Word, and then go to Help and Check for Updates.

microsoftautoupdate
You'll then see something like this, and you can change it from Automatically to Manually.

But with a bunch of Munki clients, you don't want to do that for each user. The whole point of Munki is to automate things, so what you really want to do is invoke a terminal command that you can script:

defaults write com.microsoft.autoupdate2 HowToCheck "Manual"
That one command does it for only the logged-in user if the user runs it. Any package you distribute via Munki (I'd highly recommend Packages as a way to point-and-click-create a package with no payload and only a script) will run as root, so you probably want to do something a bit more complicated to make sure you have your bases covered.

I created the following script that loops through all the existing users, changes their preferences from automatic to manual, makes sure they're still the owner of the .plist that's been changed (instead of root owning it) and then changing the default global setting from automatic to manual for any users created in the future (and, yes, I've tested it—changing it in /Library/Preferences will affect newly-created users).

#!/bin/bash

# Declare a function to delete the user files
fix_existing_users(){

# Make sure it's not the general "Shared" user
if [[ $1 != "Shared" ]]; then

sudo defaults write /Users/$1/Library/Preferences/com.microsoft.autoupdate2 HowToCheck "Manual"

# Assign a temporary variable for the exit status of the last command
rc=$?

# Check that the exit status is 0 (i.e., good)
if [[ $rc == 0 ]]; then

# Make sure, even though we ran sudo, that the user is still the owner of that file
sudo chown $1 /Users/$1/Library/Preferences/com.microsoft.autoupdate2.plist

fi

fi
}

# Loop through the /Users directory
cd /Users

for d in *
do
fix_existing_users $d
done

# Fix the global one, too
sudo defaults write /Library/Preferences/com.microsoft.autoupdate2 HowToCheck "Manual"
Just make that package and mark it in the pkgsinfo .plist as an update for Microsoft Office, and then it should push out to your users when they check for updates.

/System/Library/Keychains empty… and repercussions

The issue

We ran into a weird situation once, in which a user could not update anything. Trying to update Adobe Flash ended in an immediate error (Application Initialization Error), launching the Mac App Store led to the App Store saying it couldn't be contacted, and Chrome saying it was updated when it was several versions behind. Pretty much anything that had to contact a server for updates... couldn't.

The solution

After rebooting, checking for malware, failed proxy connections, and a bunch of other potential issues, we found out that the /System/Library/Keychains folder was empty.

So we copied the contents of that folder from another Mac, and then, magically, everything worked!

Very obscure issue and obscurer solution. Thanks to J. Pruden for finding it!