MacSysAdmin Tools Smörgåsbord

Theatre entrance to the Folkets Hus. CC Image courtesy of Metro Centric on Flickr.

Theatre entrance to the Folkets Hus. CC Image courtesy of Metro Centric on Flickr.

The MacSysAdmin 2015 conference is taking place this week in Göteborg, Sweden. In a session titled MacSysAdmin Tools Smörgåsbord, I’ll be going through a selection of tools that I’ve either written or contributed to and which are available on my GitHub repo.

Here you can find the various links to tools, posts, etc. that appear in the session slides.

Configuration Profiles

Coping with Adobe Creative Apps Deployment



Homebrew stuff

OS Install Automation




Lots more!


Tagged | Leave a comment

What’s Wrong with the Office 2016 Volume License Installer?

Office 2016 for Mac comes in an installer package that has been causing several issues for Mac sysadmins deploying it in their organizations. At least a couple posts exist already for how to “fix” the installer and deploy the software, but I haven’t seen anyone actually detail some of these issues publicly. The best way to “fix” the installer is to have Microsoft fix it so that it can be deployed the same way we deploy any other software. Office is probably the most common software suite deployed in organizations, and so it’s a very bad sign that 2016 for Mac has begun its life as an installer that cannot be deployed without workarounds and/or repackaging.

In this post, as usual I’ll go into some detail about this installer’s problems, review some known workarounds and propose some solutions.

Read More »

Tagged , | 14 Responses

Disabling First-run Dialogs in Office 2016 for Mac

Welcome dialog on first launch of Word 2016.

Welcome dialog on first launch of Word 2016.

This post is part useful tidbit and part lesson in interacting with application preferences on OS X.

Office 2016 for Mac presents “first run” dialogs to the user to market some of its new features. Sysadmins often want to find ways to disable these for certain scenarios. I actually think these are often helpful for individual users, but may be less desirable on shared workstations or kiosk-like machines where users may use Office applications frequently from a “clean” profile that has never launched Office, and the repeated dialog becomes a nuisance.

There has been recent grumbling online about Microsoft’s use of a registry-like format stored in an SQLite3 database for its user “registration” information, stored deep within a group container, and I’ve seen some assumptions that other preferences live here. While this might be the case, it seems like Office stores the “first-run” settings as standard OS X preferences within each application’s preferences. They happen to be sandboxed apps, so they actually end up getting stored inside a given application’s sandbox container. For example, Word:


Mac sysadmins also tend to get hung up on plists and their paths, when it comes to preferences stored by the OS. Storage location and format of capital-P OS X Preferences, however, is an internal implementation detail that developers aren’t really concerned with. Applications need not know or care where a preference actually gets stored, they simply ask the preferences system to handle reading and writing preferences. We should follow the model of the developers: use either the defaults or CFPreferences methods provided by Apple (either from Python or C/Objective-C/Swift) to set this. Do not use direct manipulation of plist files on disk to set preferences.

Knowing that there are some preferences stored in an app’s container plist, notice how we can still “pick these up” by asking defaults for the prefs for the current user:

➜ ~  defaults read

    AppExitGraceful = 1;
    ApplePersistenceIgnoreState = 1;
    NSRecentDocumentsLimit = 0;
    OCModelLanguage = "en-CA";
    OCModelVersion = "0.827";
    SendAllTelemetryEnabled = 1;
    SessionBuildNumber = 150724;
    SessionDuration = "4.805182993412018";
    SessionId = "9FBFC4A2-B0A5-4624-93C5-3811C77E4F1E";
    SessionStartTime = "08/06/2015 20:40:34.905";
    SessionVersion = "15.12.3";
    TemplateDownload = 1;
    WordInstallLanguage = 1033;
    kFileUIDefaultTabID = 1;
    kSubUIAppCompletedFirstRunSetup1507 = 1;

I’ve omitted many keys that existed on my machine from Word 2011 (which all start with 14), but we can see there are several that are obviously for the latest version, given the SessionVersion value. The interesting one is kSubUIAppCompletedFirstRunSetup1507, a boolean.

We can test whether this will just work as a system-wide default by deleting our user’s version and then setting it in the any-user “domain” (or “scope”):

➜ ~ defaults delete kSubUIAppCompletedFirstRunSetup1507
➜ ~ sudo defaults write /Library/Preferences/ kSubUIAppCompletedFirstRunSetup1507 -bool true

Launch Word again to verify you’re not getting a first-run dialog even though we deleted it from our user’s preferences. Close Word, and verify that kSubUIAppCompletedFirstRunSetup1507 was also not set for the current user – the preferences system doesn’t set a key for the user until the application requests setting it (possibly only if it would differ from that set in the any-user scope, which it didn’t need to because the “first run” has already happened as far as Word is concerned.

Here are other application domains that seem to look for the same preference key (Outlook and OneNote seem to have their own additional “welcome” panes; see Outlook’s FirstRunExperienceCompletedO15, for example):
Tagged , | 7 Responses