With the release of Sophos Anti-Virus 9.x, Sophos changed how their antivirus solution for Macs was installed. Where previous versions of Sophos used an installer package, Sophos has now switched to using an application to install their antivirus.
This switch was a problem for Mac admins who wanted to deploy Sophos Home Edition 9.x for personal use, as there was not an available installer package to simplify the task of deployment. Sophos Home Edition 9.2.x added additional complexity by storing many of the installer’s files and other components outside the installer in a separate Sophos Installer Components directory.
However, after doing some research and testing, it looks like it is possible to repackage Sophos Home Edition 9.2.x for personal deployment. For more details, see below the jump.
When VMware released VMware Fusion 7 Professional in September 2014, among the new items included in the Features list was this one:
The ability to access virtual machines running on VMware vSphere, VMware ESXi, and VMware Workstation directly from VMware Fusion Pro including:
- Remote display, keyboard, and mouse control
- Ability to select media for CD, DVD, floppy devices, including files on your Mac
- Ability to power virtual machines on and off and configure the network they connect to
- Ability to move virtual machines from your Mac to a remote location by dragging and dropping
- Ability to move virtual machines from a remote location to your Mac by dragging and dropping
- See the state of your remote server with at-a-glance health summary based on Activity Monitor
What this new feature meant for Mac admins was that they now had a native Mac application which they could use when managing virtual machines (VMs) on VMware’s ESXi or vSphere services. The capabilities are not as full-featured as you may find in the Windows VMware vSphere client or the vSphere web client, but they are equivalent to the ESXi or vSphere management capabilities that VMware has been building into VMware Workstation for Windows. For more details, see below the jump.
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>5</integer> <key>AutoSubmit</key> <false/> <key>ThirdPartyDataSubmitVersion</key> <integer>5</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.
Using OS X 10.8’s fdesetup tool and non-enabled admin accounts to enable users for FileVault 2 on Mavericks and Yosemite
Back in OS X 10.8.x, one of the newly-created fdesetup tool’s functions was to enable users for FileVault 2. To do so, you needed to provide both the username and password of either a previously enabled account or an admin account, as well as the password of the account you want to add.
One interesting twist was that the admin user in question did not themselves need to be enabled for FileVault 2. In my testing on 10.8.x, I found that an admin user could authorize the enabling of other accounts even if the admin account wasn’t enabled. An admin account could also enable itself using this process, by being both the authorizing admin account and the account being enabled.
In Mavericks and later, this behavior changed. If you’re using Mavericks or Yosemite, the fdesetup tool included with those operating systems now prevents non-enabled admin users from enabling other non-enabled users.
That seemed to close the book on non-enabled admin accounts being able to enable users for FileVault 2, until Google’s Macintosh Operations Team posted a script that they said would make a Mac unbootable.
As part of the discussion about that script, something really interesting was discovered. For more details, see below the jump.
Since it’s rather a long list, I’m putting it below the jump. Enjoy!