Skip to main content

@rtrouton has a great post on Self-Service OS upgrades, and in fact we have a very similar workflow. Unfortunately though, it can't be fully automated with FileVault.

Specifically we have trouble as described by the Note on installing OS X on FileVault-encrypted volumes at the bottom of the createOSXinstallPkg github page:

Installing Lion, Mountain Lion, Mavericks or Yosemite requires a reboot after the install is set up, but before the actual OS X Installer runs. When installing to a FileVault-encrypted volume, after the initial reboot, the pre-boot unlock screen appears. Someone will have to manually unlock the FileVault-encrypted volume before the actual OS X installation can occur. Once the disk is unlocked, installation should proceed normally. Apple's Install OS X.app does some undocumented (and probably non-third-party-supported) magic to cause an authenticated reboot; this bypasses the pre-boot unlock screen.

The note mentions that someone will have to unlock the encrypted volume before the OS X installation, but in our environment, and I assume most others, a user has to authenticate two times: once after the Self Service policy runs, just before the OS is installed, and once again after that, but before our post-upgrade policies and scripts run.

In my experience, using an authenticated restart in the Self Service policy is not an option, presumably because the installer environment is a different animal, and not aware of such restarts.

It would be much nicer if a user could run the policy and just walk away for a couple hours, or overnight, and come back to a fully upgraded machine at the login window.

It's hard to tell from the post whether or not Rich's FileVaulted machines also experience this, but I assume so. Has anyone found a way around it?

You can do two things to reduce the authentications.

1.) Run the Installer as root if you weren't already and it won't ask for auth (Except on 10.8 for some reason)
2.) Use the standard Install OS X app from Apple but automate it with Applescript.

Using the app but automating it allows it to do all the authenticated restart magic Apple created.

Here is some AppleScript to automate the 10.11 Installer as well as the code needed to enable Assistive Services which you'll need. I could never get it working in 10.9. 

installAutomation()
{
osascript <<EOD
tell application "System Events"
tell application "System Events" to set frontmost of process "InstallAssistant" to true
tell process "InstallAssistant"
click button "Continue" of window "Install OS X"
click button "Agree" of window "Install OS X"
click button "Agree" of sheet 1 of window "Install OS X"
click button "Install" of window "Install OS X"
end tell
end tell
EOD
}
if [[ $osVersionMajor -le 8 ]]
    then
        writeLog "Enabling Assistive Services for 10.8..."
        touch /private/var/db/.AccessibilityAPIEnabled
fi


if [[ $osVersionMajor -ge 10 ]]
    then
        writeLog "Modifying Assistive Services Database for 10.10+..."
        sqlite3 /Library/Application Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/usr/local/jamf/bin/jamfAgent',1,1,1,NULL)"
        sqlite3 /Library/Application Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/usr/bin/osascript',1,1,1,NULL)"
        sqlite3 /Library/Application Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','com.apple.Terminal',0,1,1,NULL)"
fi

Thanks @iJake,

Funny enough we actually do use the standard OS X installer on our FileVaulted Macs. We have snazzy JamfHelper dialogs, and AppleScript commands visually guiding the user through the process of double-clicking and running the installer. It works well enough, but I posted today hoping Rich, or someone, had cracked the code on the "magic" :)

I'll take a look at the AppleScript. That looks helpful!

Terms & ConditionsCookie settingsAccessibility statement