OS X admins: your clients are not getting background security updates

Have I got your attention? The more accurate (and longer) qualifier for this title should actually be: “admins who configure clients to not automatically check for software updates.”

From recent discussions in ##osx-server, some of us have determined that OS X’s “system data files and security updates” will only install automatically if a client is already configured to automatically check for updates. Many sysadmins managing OS X clients tend to disable this setting so that they can control the distribution of these updates, but aren’t aware that their clients are now no longer receiving Apple’s background updates for at several of its built-in security mechanisms, including XProtect and Gatekeeper.

Rich Trouton beat me to this post with his post yesterday, but it prompted me to do a bit more digging into trying to reproduce an issue that comes up when attempting the most obvious workarounds for this issue, which I’ll outline after giving some more context.

Update: Greg Neagle has come up with a simple but flexible workaround for the issue described below, which he’s implemented in Reposado and documented here. If you use Reposado (and you really should), look into the new --remove-config-data option that can be applied selectively to SUS updates you’re mirroring.

Read More »

Tagged , , | 11 Responses

Keeping your OS X VM guest tools current with Munki

fusion_256.pngI use VMware Fusion to test client software, deployment workflows, and using virtual machines allows me to frequently take and roll back snapshots. Over time, the VMware guest OS tools tend to drift out of date with the version of Fusion, and are reported to need updates/reinstalling. Sometimes when this happens, things like pasteboard synchronization, automatic window resolution resizing and drag-and-drop file transfers stop working. I’d like to not have to manually click “Update VMware tools..” and go install the tools manually every time I notice the tools are out of date between snapshots (which on my system seems to be frequently).

Luckily, I use Munki to manage OS X clients, and it’s great at updating software. In this post I’ll walk through the few steps I did to have all my test machines configured to automatically keep their VMware tools up to date. The same logic should apply for other software management platforms like Casper, Absolute Manage or Puppet, using their respective mechanisms for customizable discoverable attributes. This technique should work for users of Parallels, if they use a sane OS X installer for their tools. VirtualBox has yet to ship with any OS X guest tools.

Read More »

Tagged , | Leave a comment

More about suppressing diagnostics submissions popups in OS X Yosemite

With OS X Yosemite, Apple added an additional phase to the Setup Assistant: the offer to submit diagnostics info to Apple and third-party developers, which is displayed either as part of a initial setup or upon first login (similar to the iCloud prompt).


Those who administer OS X clients typically look to disable such prompts on managed machines, either to avoid annoying users in shared workstation environments or because the organization may not (or may) wish to provide diagnostics information to Apple and third-party developers.

Both Rich Trouton and myself have documented what seemed to be an additional preference key that could be configured in the com.apple.SetupAssistant domain: LastSeenBuddyBuildVersion. However, with the release of OS X 10.10.1 on November 17, some admins reported seeing this dialog pop up again, and then that it might be possible to suppress by updating this new key with the updated build number of OS X 10.10.1, 14B25.

Furthermore, whether it would show up seemed it may depend on whether the user is an admin or not. If the user was not an admin, the setup assistant window would still show but would simply show the “Setting Up Your Mac..” animation that plays at the end of the setup assistant process.


Back when Yosemite was available only as developer previews, Rich had already documented on the Apple dev forums a process that seemed to disable this diagnostics prompt. This involves writing additional keys to a file at /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist. In my testing, unchecking both checkboxes (Apple and app developers) for diagnostic submissions results in at least the following keys getting set in this plist:


I looked again at whether this was still something that comes into play given this most recent 10.10.1 update. Digging through the binary at /System/Library/CoreServices/SubmitDiagInfo seems to suggest it is, with logging messages like: Diagnostic message history store was not writeable. Will not submit diagnostic messsages, admin user was unable to write into diagnostic message history, and methods that determine whether the authenticated user is an admin user. This all confirms that the service managing the diagnostic messages expects that admin users can write directly to this file (and indeed, systems I’ve seen all set this file to have read/write access for the admin group).

I’ve since performed tests deploying an new, unbooted 10.10.1 image that contains no LastSeenBuddyBuildVersion key in com.apple.SetupAssistant, where in previous Yosemite testing I’d been setting this key via a Configuration Profile.

So as far as I can tell, it may be enough to suppress this diagnostics prompt using only a DiagnosticMessagesHistory.plist file placed at /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist, containing the above four keys. I’ve tested deploying this file within an image (built with AutoDMG) using a standard installer package with no scripts.

One could also apply these plist keys to a booted system (using Munki, for example) using a script like the following. Note the lack of the "$3" variable, meaning this script would not apply to non-booted volumes if run within a postinstall script. This script actually leaves the defaults as suggested by Apple, so tweak as desired – the objective here is to set them to something so that this phase of the Setup Assistant does not show.

I consider this all still speculative. Rich Trouton has (also today) documented an alternate approach to suppressing this diagnostics dialog. My theory at this time of writing is that while perhaps updating the setting for LastSeenBuddyBuildVersion in the Setup Assistant prevents these additional screens from showing, it’s not what is actually determining the behavior of the diagnostics reporting mechanism.

Tagged , , | Comments closed