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.
This is a really odd situation. I have one client machine that cannot download a particular Apple update. This is the error message that comes up:
Software Update Tool
Finding available software
Error downloading Security Update 2017-002: The Internet connection appears to be offline.
Error downloading updates.
- The machine can contact any random website, including Apple's.
- The machine eventually could even download and install the Safari update from the Apple servers.
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.
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.
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.
Under Help, select Check for Updates....
That should show you the location of the downloaded installer.
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.
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.
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:
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).
# Declare a function to delete the user files
# 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
# 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
# Loop through the /Users directory
for d in *
# Fix the global one, too
sudo defaults write /Library/Preferences/com.microsoft.autoupdate2 HowToCheck "Manual"
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.
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!