Apple Configurator 2.0 (packaging question)

Thoughts:
- For the symlinks, possibly obtain the installer package via this method
- For the preferences, use a Custom Settings Configuration Profile for the "com.apple.configurator.ui" domain?
- Otherwise, for the preferences use Outset or a login policy to run:

/usr/bin/defaults write com.apple.configurator.ui HasInstalledAutomation -bool true
/usr/bin/defaults write com.apple.configurator.ui LastAcceptedConfiguratorLicenseVersion EA1353

Then you don't have to worry about looping through users.

Oh, wait, upon further review you say the symlinks are created at launch? May need to run a script after installation if that's truly when they're created (e.g. when the MAS package isn't used).

Yea, plus will this work with sandboxed apps?

FWIW, 1.7.2 is sandboxed but the only two things that are annoying are the EULA and Welcome window, which don't require admin rights. Unfortunately v2 has that feature that requires admin rights on first launch.

So we are just using the MAS package unmodified for deployment and we aren't getting the admin account prompt. Just the license agreement. Not sure why that would be... The license agreement to me isn't a big deal for this package so i have just let the user click it.

@foigus wrote:

Oh, wait, upon further review you say the symlinks are created at launch? May need to run a script after installation if that's truly when they're created (e.g. when the MAS package isn't used).

Yes the script is run after installation. The defaults command is needed for the app to know they're already there. Looping through users' home directories containers plist files don't seem to be getting it done. Could this be related to sandboxing?

@joecurrin do you see the Apple Configurator 2 > Install Automation Tools... option after launching? Does it prompt for admin rights? The EULA isn't a deal breaker for us, we're not too concerned about it.

@donmontalvo I'm only going by the command you shared, but if those commands are being run by root or any other user as is, then you also need to correct ownership on the file after it's been created (particularly if you're just looping through all home directories.

Sorry to get a little inception-y here, but since I've already mentioned this before its easier than repeating myself:
https://jamfnation.jamfsoftware.com/discussion.html?id=18569#responseChild110522

If this is not at all what you're experiencing then please disregard my comment :)

@bpavlov thanks, and no worries, all feedback is welcome. :) We are looping through after setting these, with a command to set ownership to that user, for example:

/usr/bin/defaults write /Users/"$u"/Library/Containers/com.apple.configurator.ui/Data/Library/Preferences/com.apple.configurator.ui.plist HasInstalledAutomation -bool true
/usr/bin/defaults write /Users/"$u"/Library/Containers/com.apple.configurator.ui/Data/Library/Preferences/com.apple.configurator.ui.plist LastAcceptedConfiguratorLicenseVersion EA1353
chown -R "$u" /Users/"$u"/Library/Containers/com.apple.configurator.ui/Data/Library/Preferences/com.apple.configurator.ui.plist

Circling back a few months later to get Apple Configurator 2.2 deployed, and as in original post, creating two symbolic links after install.

Through trial and error, it seems Apple Configurator 2.2 has to be launched by the current user first, for their app specific sandboxed folders/files to be created.

Then we can use Self Service to grab the logged in username, and apply the key, using a blend of commands from @mm2270 and @elliotjordan:

#!/bin/sh
username=$(/usr/bin/stat -f%Su /dev/console)
sudo -u $username defaults write com.apple.configurator.ui HasInstalledAutomation -bool true
sudo -u $username defaults write com.apple.configurator.ui LastAcceptedConfiguratorLicenseVersion EA1353
exit 0

That writes it to /Users/username/Library/Containers/com.apple.configurator.ui/Data/Library/Preferences/com.apple.configurator.ui.plist

If the user does this without first launching Apple Configurator 2.2, the app crashes, or doesn't crash and doesn't take the new setting.

We're going to open a case with AppleCare, there has to be a way to manage these things better in enterprise environments. Even if we had VPP (coming soon!), we would still be faced with this issue.