Archive for December, 2015

2015 in review

December 29, 2015 Leave a comment

The stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 1,500,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 64 days for that many people to see it.

Click here to see the complete report.

Categories: Technical

Managing El Capitan’s FileVault 2 with fdesetup

December 20, 2015 5 comments

For the first time since fdesetup‘s initial release in OS X Mountain Lion 10.8.x, Apple has not added new features to fdesetup as part of a new OS release. Instead, fdesetup maintains the same set of features in OS X El Capitan 10.11.x as it had in OS X Yosemite 10.10.x.

This decision may mean that fdesetup, an essential command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption, is now considered by Apple to be a fully-developed toolset for managing FileVault 2.

fdesetup gives Mac administrators the following command-line abilities:

  • Enable or disable FileVault 2 encryption on a particular Mac
  • Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
  • Enable one or multiple user accounts at the time of encryption
  • Get a list of FileVault 2-enabled users on a particular machine
  • Add additional users after FileVault has been enabled
  • Remove users from the list of FileVault enabled accounts
  • Add, change or remove individual and institutional recovery keys
  • Report which recovery keys are in use
  • Perform a one-time reboot that bypasses the FileVault pre-boot login
  • Report on the status of FileVault 2 encryption or decryption

I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.

Read more…

Updated System Integrity Protection status reporting script

December 18, 2015 Leave a comment

After writing a Casper Extension Attribute script to report on the status of System Integrity Protection, I realized that I hadn’t accounted for reporting SIP’s custom configurations. These are configurations where SIP is enabled, but one or more of SIP’s protections or restrictions has been disabled. I’ve now updated the script to also report on the following SIP configurations:

  • Kext Signing: disabled
  • Filesystem Protections: disabled
  • NVRAM Protections: disabled
  • Debugging Restrictions: disabled
  • DTrace Restrictions: disabled

For more details, please see below the jump.

Read more…

Casper Extension Attribute script to report System Integrity Protection status

December 16, 2015 Leave a comment

To follow up on Apple’s changing the output of csrutil status when System Integrity Protection (SIP) is disabled, I’ve posted the following Casper extension attribute to my GitHub repo to report on whether SIP is enabled or disabled.

osvers_major=$(sw_vers -productVersion | awk -F. '{print $1}')
osvers_minor=$(sw_vers -productVersion | awk -F. '{print $2}')
# Checks to see if the OS on the Mac is 10.x.x. If it is not, the
# following message is displayed without quotes:
# "Unknown Version Of Mac OS X"
if [[ ${osvers_major} -ne 10 ]]; then
echo "<result>Unknown Version of Mac OS X</result>"
# Checks to see if the OS on the Mac is 10.11.x or higher.
# If it is not, the following message is displayed without quotes:
# "System Integrity Protection Not Available For" followed by the version of OS X.
if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -lt 11 ]]; then
echo "<result>System Integrity Protection Not Available For `sw_vers -productVersion`</result>"
if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -ge 11 ]]; then
# Checks System Integrity Protection status on Macs
# running 10.11.x or higher
SIP_status=`/usr/bin/csrutil status | awk '/status/ {print $5}' | sed 's/\.$//'`
if [ $SIP_status = "disabled" ]; then
elif [ $SIP_status = "enabled" ]; then
echo "<result>$result</result>"

view raw


hosted with ❤ by GitHub

The script has the following functions:

If the Mac is running 10.10.x or earlier

The script reports System Integrity Protection Not Available For and then reports the relevant version of OS X. For example, the script returns the following output on a Mac running OS X 10.10.5:

System Integrity Protection Not Available For 10.10.5

If the Mac is running 10.11.x or later

This script uses csrutil status to check SIP’s status. If System Integrity Protection is disabled, the script returns the following output:


If System Integrity Protection is enabled, the script returns the following output:


For those interested, the script is available on my GitHub repo:

System Integrity Protection’s csrutil status’ message change for OS X 10.11.2

December 16, 2015 3 comments

In order to check whether System Integrity Protection (SIP) is enabled or disabled on a Mac running OS X El Capitan, you can use the csrutil command to report on SIP’s current status. For example, to learn if SIP is enabled or disabled, run the following command:

csrutil status

This command can be run without root privileges and will tell you if SIP is on or off.

If SIP is enabled on 10.11.0 or higher, you should receive the following message:

System Integrity Protection: enabled

Csrutil status enabled run outside recovery

If SIP is disabled on OS X 10.11.0 or 10.11.1, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.

Csrutil status disabled run outside recovery 10101

It appears that Apple has updated the status message on OS X 10.11.2 to make it much more clear when SIP is disabled. On 10.11.2, if SIP is disabled, you now should receive the following message:

System Integrity Protection: disabled

Csrutil status disabled run outside recovery 10102

Fixing the OS version of transferred ESXi-hosted OS X VMs

December 16, 2015 3 comments

Starting with VMware Fusion 7.x Professional, it’s been possible to transfer virtual machines from VMware Fusion to VMware ESXi. This ability has been improved with VMware Fusion 8.x Professional, but there is a recurring issue with OS X VMs transferred from VMware Fusion to VMware ESXi 6.x. The symptoms normally look like this:

1. An OS X VM running OS X 10.10.x or 10.11.x is created in VMware Fusion 8.x Professional
2. The hardware version of the OS X VM is changed to Hardware Version 11, to allow compatibility with ESXi 6.x

Screen Shot 2015 12 15 at 7 49 24 PM

3. The VM is transferred successfully to VMware Fusion 8.x Professional to the ESXi 6.x server
4. Following the transfer, the OS X VM is started but does not successfully complete the OS startup process.

Screen Shot 2015 12 15 at 9 22 41 AM

The root cause is that there is some OS information which is not transferred successfully along with the VM, but it’s relatively straightforward to fix. For more details, see below the jump.

Read more…

Status report script for Linux-hosted Casper servers

December 14, 2015 1 comment

As part of keeping an eye on my support systems, I’ve been using a script for my Casper servers running on Linux which emails me a status report on a daily basis. I adapted this script from an earlier one I wrote to monitor Tomcat and alert me if Tomcat was having issues. The script tells me a number of things that are useful to know, including the following:

  • Uptime
  • Free space on all attached drives
  • Who’s logged in via SSH or in the console
  • Virtual memory statistics
  • Current system tasks
  • SMB connections information
  • Recent entries in the Apache server logs
  • Recent entries in the JSS server log

In my case, my Casper servers are hosted on Red Hat Enterprise Linux so I’ve focused this script’s development and testing on compatibility with RHEL-based Linux distributions. That said, nothing in it is RHEL-specific so it should also work on other Linux distributions. For more information, see below the jump.

Read more…

Categories: Casper, JSS, Linux, Scripting

Upgrading to OS X El Capitan using the OS X 10.11.2 installer removes package installation receipts

December 11, 2015 4 comments

Following the recent release of OS X El Capitan 10.11.2, it appears that the OS X 10.11.2 installer has an unexpected and unwelcome behavior. When upgrading from an older version of OS X to OS X 10.11.2 while using the OS X 10.11.2 installer, the /var/db/receipts directory is being removed as part of the OS upgrade process. This directory is used by OS X to store a database of receipts for software installed using an installer package, which provides a historical record of what software has been installed on a particular Mac.

The removal of the receipts database is particularly problematic for software installation management tools like Munki and Simian, as they leverage the information in the receipts database to determine which software has been installed (or not installed) on a particular Mac. Other system management tools that leverage the receipts database may be affected by this issue as well.

As this behavior appears to be coming from Apple’s OS X installer, this behavior has been observed in both Apple’s OS X installer and in OS X installer packages generated by createOSXInstallPkg.

A bug report has been filed with Apple about this behavior by Mike Solin. For those who want to file a duplicate report, it is bug ID 23853195. The information in the bug report has also been posted to Open Radar, available via the link below:

Fortunately, this behavior does not appear to apply to Apple’s OS X 10.11.2 updates for Macs already running OS X El Capitan. Updating from OS X 10.11.0 or 10.11.1 to OS X 10.11.2 using Apple’s OS X El Capitan 10.11.2 Update or OS X El Capitan 10.11.2 Combo Update does not result in the /var/db/receipts directory being removed, meaning the existing receipts database remains in place and is not deleted.

For those who want to provide upgrades from older versions of OS X to El Capitan and want to avoid this problem, the best course of action at this time is to do the following:

  1. Use an OS X El Capitan 10.11.0 or 10.11.1 installer to upgrade the Mac in question to El Capitan
  2. Following the OS upgrade, use Apple’s software update tool to update the Mac to OS X 10.11.2

Deploying and licensing Endnote X7

December 3, 2015 2 comments

In my shop, a number of folks use Thomson Reuter’s Endnote bibliography software. Thomson Reuter makes Endnote available with a drag-and-drop installer, but I need an installer package in order to deploy it in my shop. For various reasons, my existing process to build an installer package for it has been a fairly hands-on process and I’ve been wanting to introduce automation to this task for a while.

As a consequence, I was pretty happy when several folks posted AutoPkg recipes for Endnote, including a recipe that would automate uploading the latest Endnote installers to my Casper server. The main hitch there was that the Endnote installer from AutoPkg installs an unlicensed copy of Endnote and I needed to have installed copies of Endnote automatically use my shop’s Endnote site license.

Screen Shot 2015 12 03 at 2 28 32 PM

After some digging around and checking files, I discovered that Endnote X7’s license file is stored as an invisible file in /Applications/Endnote X7. It is named .license.dat and has a format that looks like this:

Company Name

Note: The Company Name part may show up twice in your .license.dat file.

With some additional testing, I found that I could remove an existing .license.dat file (if one was present) and replace it with a site license’s .license.dat file. That allowed me to use the Endnote installer produced by AutoPkg by having Casper install it, then apply our site license file as a post-installation action. For more details, see below the jump.

Read more…

Setting Microsoft Outlook as the default application for email, contacts and calendars via Automator

December 1, 2015 10 comments

While working on an Outlook 2016-related issue earlier this week, I found that there is not a straightforward way to set Microsoft Outlook 2016 as the default application for email, contacts and calendars. To redress this, I’ve developed an Automator application named Set Microsoft Outlook as default application for email calendars and to handle this task.

The Set Microsoft Outlook as default application for email calendars and contacts application leverages duti, an open source tool used for managing application ownership of document types and URL schemes on Mac OS X, to set the newest version of Microsoft Outlook on the Mac as the default application for email, contacts and calendars.

The application includes an embedded copy of duti, so it is not necessary to have duti pre-installed on the Mac in order to use this tool. For more details, see below the jump.

Read more…

%d bloggers like this: