Munki is a great tool for distributing software and creating little mini App Stores for organizations, so users can do self-service installs of Mac software.
But Munki is also a great tool for keeping software up to date. Some software updates are primarily about adding new features. Many updates, however, include bug fixes or security patches (for example, Adobe Flash needing to be patched recently).
Instead of pestering users with emails “Make sure ya’ll install this Flash update” or hoping users heed the pestering of the app itself, Munki can do a lot of updates to applications automatically.
Every now and then, though, you may need to bother your users to install an update. How can you get that good balance of keeping things up to date and not bothering your users too often?
Check for Munki updates at a scheduled time each day
By default, Munki checks in with the server about once every hour or so. If you have desktop computers you know will be on at a certain time (and not in use), you may want to schedule them to run at a specific time once a day when users are logged out.
For example, we have some shared desktop computers that boot up in the early morning every day. So, we have them scheduled to check for updates once every morning well before school begins, so no students should be logged into any of the machines, and Munki is free to install software updates, even ones that require a logout or reboot.
To change the time of the checkins, make a copy of the /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist file (your new one can be com.googlecode.munki.managedsoftwareupdate-check.revised.plist):
Here’s an example of running once a day around 6:10-6:30 AM:
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
On the Apple website, you can find more details on the StartCalendarInterval parameters.
Then you want to make it so the original .plist doesn’t run:
Increase the interval between user notifications
You can see in the Munki documentation about preferences that there is something called SuppressUserNotification, which defaults to false. You can change that to true instead, but I prefer to keep it as is and use the DaysBetweenNotifications parameter in /Library/Preferences/ManagedInstalls to notify users less frequently (say, once every two weeks). I’ve since changed my position on this, and SuppressUserNotification actually seems to be the way to go (at least for me, working in a school environment). More details in Not bothering teachers with Managed Software Center notifications during the school day. That, combined with, on the server, marking most software as unattended_install items (more details under Pkginfo Files).
If a package is marked as an unattended install, Munki will try to update in the background without notifying the user. To prevent data loss, you may want to make certain applications have a blocking application or an installs array in the pkgsinfo .plist file to make sure the app doesn’t die while the user is using it. The major plugins (Java and Flash) seem to be fine to update even while the user is using them, but be sure to test before you mark anything as an unattended install.
Schedule the suppression of login window installs
This works for only computers you know will be logged out of fairly often (for example, shared machines bound to Active Directory). You can have a nopkg that runs every Munki run and toggles the SuppressLoginwindowInstall preference flag depending on the time of day. Here’s an example.
That way, at the beginning of the day (or end of the day—however you want to schedule it), you can disable the suppression of login window installs, have those installs happen, and then background unattended installs can happen throughout the day without bothering users or covering up the login screen with a Managed Software Center progress dialogue.
Make updates available less frequently
One way to not bother users with updates is simply not to update very frequently. So if you have Autopkg fetching new versions of applications, you can schedule Autopkg to run only once a week or once every couple of weeks. Or you can schedule Autopkg to run every day and load into the testing catalog but then not mark updates as available in your production catalog until two weeks later.