One of the pop-up windows you get on first login to Yosemite is the Diagnostics & Usage pop-up window. This window requests permission for the following:
- Send diagnostics and usage data to Apple
- Share crash data with non-Apple developers
I’ve been suppressing this window without setting those diagnostic reporting settings, but Mac admins may also want to apply those settings as part of building their machines. Thanks to investigative work by Tim Sutton, it looks like it’s possible to control those settings by setting the correct values in the /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist file.
<key>AutoSubmitVersion</key> <integer>4</integer> <key>AutoSubmit</key> <false/> <key>ThirdPartyDataSubmitVersion</key> <integer>4</integer> <key>ThirdPartyDataSubmit</key> <false/>
For more details, see below the jump.
When I updated to 10.10.1 yesterday, as part of the restart process I noticed that I was seeing the Diagnostics pop-up window appear on login.
I had previously suppressed this window as part of setting up this machine, but it looks like the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist had the build number for 10.10.0 stored and it needed to be updated with the build number of 10.10.1 in order to suppress the Diagnostics pop-up window again.
Fortunately, this can be addressed by setting up an automated run of my iCloud / Diagnostics suppression script with Casper. This should automatically update the LastSeenBuddyBuildVersion value in /Users/username/Library/Preferences/com.apple.SetupAssistant.plist with the build number for the current version of 10.10.x. For more details, see below the jump.
I’ve updated the create_vmware_osx_install_dmg.sh script which I had previously posted about here. The script now includes support for Yosemite, so the script can now be run on 10.7 – 10.10 to create custom OS X 10.7.x, 10.8.x, 10.9.x and 10.10.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.
With the release of Yosemite, Apple has apparently made an undocumented change to the way it allows packages to be added to the OS installer. If you add any additional packages for installation as part of the OS install/upgrade, they must all be distribution-style flat packages. You can convert a component flat package to be a distribution-style flat packages by running the command below:
productbuild –package /path/to/component.pkg /path/to/distribution.pkg
This change is a problem for First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg, as they are both built as a bundle-style package and not as flat packages. While both First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg run fine on Yosemite, they cannot be added to customized NetInstall images created with System Image Utility or to createOSXinstallPkg-built Yosemite OS installer packages.
To address this issue, I’ve developed First Boot Package Install Generator.app, an Automator application that will allow the selection of a folder containing installer packages and then generate a distribution-style flat package that enables the selected packages to be installed at startup. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be used as part of a createOSXinstallPkg deployment workflow. See below the jump for the details.
For the past few major releases, Sophos used a standard installer package to install both their free and paid antivirus solution. With the release of Sophos Anti-Virus 9.x though, Sophos changed how their antivirus solution for Macs was installed. Sophos has now switched to using an application to install their antivirus. However, for their customers using Sophos Enterprise Console, Sophos still provides an installer metapackage. This is good news for Mac admins, but the configuration and login credentials that used to be stored in /Library/Preferences/com.sophos.sau.plist in Sophos 8.x has been overhauled in Sophos 9.x. /Library/Preferences/com.sophos.sau.plist in Sophos 9.x now no longer contains login information, only server locations.
The login credentials no longer being available in /Library/Preferences/com.sophos.sau.plist meant that the Sophos Anti-Virus client was not able to connect back to the Sophos enterprise console and receive either management or updates. Since those login credentials were working in my shop for machines in Active Directory OUs that the Sophos enterprise console was managing, that meant that those credentials were available somewhere on the system. After working on the problem in his own shop, Tim Kimpton figured out that both of the following files were needed:
Once I had this information and understood what was going on, I was able to build and deploy a Sophos Enterprise Anti-Virus for Mac OS X 9.x installer that was able to install a pre-configured set of auto-update settings. For more details, see below the jump.
While working recently on First Boot Package Install.pkg, I decided to implement a way to automatically install all available Apple software updates along with enabling other packages to be installed at first boot. After some work and testing, I’m happy to announce the release of First Boot Package Install With Automated Apple Software Update.pkg.
The main difference between First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg is that before installing the user-selected packages, all available Apple software updates are downloaded and installed. By design, the First Boot Package Install With Automated Apple Software Update.pkg script will use Apple’s softwareupdate tool to check for and install available updates, then reboot the Mac automatically until all available updates have been installed.
As not all shops that may want to use First Boot Package Install.pkg will find this functionality to be needed or desirable, I’ve set up a new repo on Github for First Boot Package Install With Automated Apple Software Update.pkg. That way, Mac admins will be able to choose which one they want to use.
All First Boot Package Install With Automated Apple Software Update.pkg components and scripts are available at my GitHub repo:
Please see the README available at the repo for how to use First Boot Package Install With Automated Apple Software Update.pkg. The Iceberg project files are also available via the link above if you want to build a customized First Boot Package Install With Automated Apple Software Update.pkg for your own environment.
Following up on a pull request by Matthew Kweskin, I’ve updated First Boot Package Install so that it now reports whether an installation has succeeded or failed. This error reporting is in addition to the error logging recorded by OS X’s installer tool to /var/log/install.log.
For those interested, here are the changes to First Boot Package Install‘s firstbootpackageinstall.sh script.
I’ve updated the First Boot Package Install GitHub repo with the new First Boot Package Install installer package, along with updating the posted firstbootpackageinstall.sh script and the Iceberg project files with the changes.