For those who wanted a copy of my security talk at JAMF Nation User Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2015SecurityPDF

Keynote – http://tinyurl.com/JNUC2015SecurityKeynote

@clburlison has discovered that you can take screenshots of the OS X login window on OS X El Capitan using OS X’s keyboard shortcuts for making screenshots.

This appears to be a new feature of El Capitan, as I was unable to reproduce this behavior on OS X Yosemite.

In my testing, I’ve verified that using the following commands work:

• Take a screenshot of the entire login window: Command+Shift+3
• Take a screenshot of a user-selected area of the login window: Command+Shift+4

The screenshot file(s) will then appear on the desktop of the next user to log in.

To distinguish these login window screenshots from screenshots taken while logged in, the login window screenshots’ filenames begin with LW.

I’ve updated the create_vmware_osx_install_dmg.sh script that I had previously posted about here. The script now includes support for El Capitan, so the script can now be run on 10.7 – 10.11 to create custom OS X 10.7.x, 10.8.x, 10.9.x, 10.10.x and 10.11.x installers for VMware Fusion and VMware ESXi. See below the jump for the details.

Downloading the script and support files

Download a .zip archive containing all needed files from my GitHub repo. This will give you both the create_vmware_osx_install_dmg script and a directory named support which contains files that the script will be copying into the completed disk image.

Both the create_vmware_osx_install_dmg script and the support directory must be stored in the same directory in order for the script to work properly.

Once you have the .zip archive download and uncompressed, go into the support directory and unzip the First_Boot_Package_Install.zip file. First Boot Package Install.pkg is used by the script so it’ll need to be unzipped and prepared before running the script.

Note: The First Boot Package Install.pkg included with this script will automatically install all available Apple software updates following the OS installation, but provide no other customization for the VM.

Creating a customized first boot package

If you want to have a first boot package that installs other packages at first boot, I’ve written a tool named First Boot Package Install Generator.app that will generate a first boot package that works with this script.

NOTE: The customized OS X installer will have an upper limit of 350 MBs of available space for added packages. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

For details on how to use First Boot Package Install Generator.app to generate your first boot package, please see this post:

https://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

When using a first boot package with this script, the script has the following hard-coded requirements:

1. That the first boot package is named First Boot Package Install.pkg
2. That the first boot package is stored in the support directory.

Running the script to create a customized OS X install .dmg file

Once you have the first boot package available and configured to your preferences, run the create_vmware_osx_install_dmg script with two arguments:

1. The path to an Install OS X.app or the InstallESD.dmg contained within.
2. A directory to store the completed disk image in.

Example usage:

If you have a 10.11.0 El Capitan installer available, run this command:

sudo /path/to/create_vmware_osx_install_dmg.sh "/Applications/Install OS X El Capitan.app" /path/to/output_directory

If you had chosen to not create the .ISO file, this should produce a DMG file inside output_directory that’s named something similar to OSX_InstallESD_10.11_15A284.dmg. This DMG will install both OS X 10.11.0 and the first boot package.

If you chose to also create the .ISO, you should have two files inside the chosen directory: OSX_InstallESD_10.11_15A284.dmg and OSX_InstallESD_10.11_15A284.iso

Creating a VM with the customized OS X install .dmg file

1. Launch VMWare Fusion 8.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your customized OS X install disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

• Operating System: Apple OS X
• Version: OS X 10.11

7. In the Finish window, select Customize Settings if desired.

Otherwise, click Finish.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the customized OS X installer disk image. To install OS X and the packages included with your first boot package, start the VM and then do nothing. The VM should begin automatically installing OS X on the VM’s boot drive, followed by the installation of the first boot package.

If you want to build a customized version of this script, the script and its associated files are available on Github at the following address:

https://github.com/rtrouton/create_os_x_vm_install_dmg

For the past couple of releases, Oracle has used a standard installer package to install Java 8. With the release of Java 8 Update 65 though, Oracle returned to using an application to install Java.

This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 65 using a standard installer package. For more details, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle has stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Now that the good news is covered, let’s talk about the install application. Oracle’s Java 8 Update 65 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

As best as I can tell, that’s it. Unlike previous incarnations of the install application, the Java 8 Update 65 install application does not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. All the functionality to do so is still contained within the MacJREInstaller binary though, so I plan to keep a close eye on this. For those interested, I’ve posted the output below.

Following closely on the heels of Oracle’s release of Java 8 Update 65, Oracle has released Java 8 Update 66. This update is also using Oracle’s install application.

What’s the difference between Update 65 and Update 66? Update 65 is a Critical Patch Update (CPU), which contains both fixes to security vulnerabilities and critical bug fixes. Update 66 is a Patch Set Update (PSU), which means it contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems. For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

So the short version is that Update 65 has “critical bug fixes” and Update 66 has “Update 65’s bug fixes, plus more bug fixes.”

You can get Oracle’s Java 8 Update 66 from the link below:

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

For more details on Java 8 Update 66, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Oracle’s Java 8 Update 66 install application has the following behavior:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

Unlike previous incarnations of the install application, Java 8 Update 65‘s and Java 8 Update 66‘s install applications do not appear to try to install any browser toolbars. To verify this behavior, I ran the MacJREInstaller binary which the Oracle Java application is using to actually install the Java browser plug-in.

While I observed that Java 8 Update 66’s MacJREInstaller continued to check with Oracle and report which country it was being installed in, I did not see anything being downloaded from Oracle. This behavior matches what I observed with Java 8 Update 65. For those interested, I’ve posted the output below.

As part of the development of Mac OS X, Apple has also developed Mac OS X Server as a way to provide access to both additional services on OS X and the management tools needed to administrate those services. While Mac OS X and Mac OS X Server used to be separate operating systems, Apple combined them into one release re-branded as OS X and moved the server-specific services and management tools into an OS X Server application available from the Mac App Store.

As part of the move to an application-based installation process, there was a capability removed from OS X Server: The ability to automate its setup entirely from the command line.

In order to run the initial setup of OS X Server, the following manually-run process was needed:

1. Log into the Mac using an account with administrator rights
2. Launch /Applications/Server.app

3. Agree to the OS X Server license

4. Provide administrator authorization when prompted.

5. The initial setup of OS X Server would then proceed.

For Mac sysadmins who needed to set up multiple instances of OS X Server, having this manual step involved slowed the setup process down considerably. To find out why this part needed to run manually, while at WWDC 2015 I asked the relevant Apple engineer why this was the case. The response was that the OS X Server license needed to be agreed to, to which I mentioned that Xcode had a similar requirement but that there was a way to agree to the license from the command line. The Apple engineer in question took that feedback and said it was a valid point.

At this point, the story skips forward to Brad Chapman discovering a new and undocumented way to agree to the license from the command line in OS X Server 5.0.x. Charles Edge built on that discovery and created an expect script to handle agreeing to the license and providing admin authorization. Charles’s method incorporated the use of an existing admin user’s username and password in the script, so in turn I’ve built on Charles’s work to create a completely automated setup script which does the following:

1. Create a temporary user with a randomly generated password
2. Give the temporary user admin privileges
3. Run the initial setup and configuration of OS X Server’s services.
4. Delete the temporary user

As part of the initial setup process:

• Agree to the license
• Authorize the setup process using the temporary user’s username and password

For more details, see below the jump.

This script is designed to automate the setup of OS X Server 5.0.3 and later by authorizing and using the server tool within /Applications/Server.app to run the initial setup and configuration of OS X Server’s services.

When launched, the script will check for the existence of the server setup tool. If the server setup tool is not located where the script expects it to be, the script will exit.

If the server setup tool is located in the expected location, the script will proceed with the following previously-mentioned actions:

1. Create a temporary user with a randomly generated password
2. Give the temporary user admin privileges
3. Run the initial setup and configuration of OS X Server’s services.
4. Delete the temporary user

As part of the initial setup process:

• Agree to the license
• Authorize the setup process using the temporary user’s username and password

I’ve tested this script with OS X Server 5.0.3 on both OS X 10.10.5 and OS X 10.11.1. In both cases, the script was able to run the initial setup and configuration of OS X Server’s services.

I’ve also verified that the script runs properly while the Mac is sitting at the login window. I tested this by creating a firstboot package with the Server.app installer package and a payload-free package containing this script. When the firstboot process ran, Server.app was installed, then the script ran the initial setup and configuration of OS X Server’s services.

The script and its associated payload-free package are available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/setup_osx_server_dot_app

For those who wanted a copy of my security talk at MacTech Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MT2015SecurityPDF

Keynote – http://tinyurl.com/MT2015SecurityKeynote

JAMF Software has posted the session videos for from JAMF Nation User Conference 2015, including the video for my OS X security session.

For those interested, all of the the JNUC 2015 session videos are available on YouTube. For convenience, I’ve linked my session here.

With the release of Java 8 Update 65, Oracle has returned to using an application to install Java. This switch away from using installer packages is a problem for Mac admins who need to deploy Oracle’s Java 8 in their own environment. However, after doing some research, it looks like it is still possible to deploy Oracle’s Java 8 Update 65 using a standard installer package. For more details, see below the jump.

While the Oracle install application is not a standard installer package, it appears that Oracle had stored an installer package for Java 8 within the install application at the following location:

/path/to/install.app/Contents/Resources/JavaAppletPlugin.pkg

Once the JavaAppletPlugin installer package is copied out of the install application, it can be deployed like previous Java updates’ installer packages.

Now that the good news is covered, let’s talk about the not-good news because this install application’s behavior has changed very recently. Oracle’s Java 8 Update 65 application has the following behavior as of November 13th, 2015:

This application will prompt for admin privileges before fully launching.

Once you provide admin authentication, the application launches.

You will be prompted to set Yahoo.com as your browser homepage, with the choice to do so checked off by default.

It will confirm this choice.

It will then tell you how many devices run Java while it installs.

Once complete, it’ll tell you what it’s installed.

The fascinating part is that Safari’s homepage doesn’t actually change to be Yahoo and there is not a new Safari extension installed. This may be because of recent changes in Safari 9.x, which tightened the requirements for installing Safari extensions.

It also doesn’t appear that Safari is unique in this regard, as the installer will check for the default browser and try to change the home page and install toolbars there as well. In my testing, this had the following results:

If Safari is your default browser, the Java install application offers to install a toolbar and set new homepage in Safari. It doesn’t set Safari’s homepage and does not install a Safari extension.

If Firefox is your default browser, the Java install application offers to install a toolbar and set new homepage in Safari. The Java 8 install application then quits midway through the installation process.

If Google Chrome is your default browser, the Java install application offers to install toolbar and set new homepage in Safari and Chrome.

It doesn’t set Chrome’s homepage, but it does re-set Safari’s homepage to Yahoo (while simultaneously failing to install toolbars in either.)

Meanwhile, Chrome is unable to run the Java browser plug-in.

Circling back to the JavaAppletPlugin installer package mentioned earlier in the article, it appears that this installer does not install any toolbars or reset the homepage setting for the default browser. To avoid having to deal with Yahoo-driven annoyances, I recommend using the JavaAppletPlugin installer package whenever possible.

As part of my work, I occasionally need to download installer packages for certain applications from the Mac App Store. In particular, I routinely download and archive certain Apple applications from the MAS to guard against the possibility that Apple will remove older versions of a particular application that I still need to have available.

A tool that has helped me with this has been Max Schlapfer‘s AppStoreExtract script. This script is designed to make copies of the installers from the Mac App Store, and is able to handle multiple installer downloads at once.

AppStoreExtract is available from GitHub at the following address:

https://github.com/maxschlapfer/MacAdminHelpers

For more details on how to download installers from the MAS using AppStoreExtract, see below the jump.

1. If needed, download the AppStoreExtract script and store it in a convenient location.

2. Once the AppStoreExtract script is available, open the Mac App Store and sign in with the appropriate Apple ID for the applications in question.

3. Open Terminal and begin running the script.

Note: Run the script with the logged-in user’s privileges. Do not run this script with root privileges, as the script will not locate the appropriate Mac App Store download folder when running as root.

4. You’ll be notified that you can press any key to finish the process once the software has been downloaded from the MAS.

5. Go to the Mac App Store’s Purchased list.

6. Click the Install button for the desired application(s).

7. Wait for the MAS to complete installation of all the desired applications.

8. Go back to Terminal and press any key.

9. When prompted to finalize the packages, press the Y key followed by the Return key on your keyboard.

10. The script will rename the downloaded installers to match the application name and version, then create a disk image with the installer package contained inside.

11. The disk images will be stored in /Users/Shared/AppStore_Packages

These downloaded installers will be signed with the Mac App Store’s certificate. From there, you can use it on its own or as part of a deployment workflow.

When the applications in question are installed on a Mac using the downloaded installer package, there will not be a _MASReceipt from the App Store included as part of the application. This means that the applications are not tied to a specific Apple ID.

To help the folks in my shop keep their Macs updated to the latest version of OS X, I’ve been providing a Self Service-driven OS upgrade option via Casper for the past couple of years. For a high-level overview, here’s how the process looks for El Capitan from my folks’ perspective.

1. Launch Casper’s Self Service application.

2. Locate the El Capitan Upgrade option

3. Click on the Install OS X button.

4. In the next window that pops up, they’re given important information about the OS upgrade and need to click again on the Install OS X button.

If their Mac does not have sufficient free space available available on their boot drive, they receive a warning message and the upgrade process stops at this point.

If their Mac’s boot drive has sufficient free space available, they receive a message that OS X 10.11.x is downloading and preparing for installation. Once all preparations are complete, their Mac will automatically reboot to begin the installation process.

5. Once the Mac reboots, the OS upgrade process runs. Once completed, the Mac reboots.

6. Following the reboot, an automated post-upgrade process runs. This process will update the Mac with all available Apple updates along with applying my shop’s preferred settings for the new version of OS X.

Note: This process may involve several reboots, depending on what Apple updates are needed. Once the post-upgrade process completes, the Mac will reboot again.

7. Following the reboot, the Mac will boot to the login window. At this point, the OS upgrade process has been completed and it is OK to log in and begin working again.

To see how I’ve set up this workflow using Casper and other tools, please see below the jump.

The OS X upgrade method that I’m using leverages createOSXinstallPkg, which is a tool that allows you to create an installer package from Apple’s OS X installers. The resulting installer package can be used in the following ways:

• Installing OS X on an empty partition
• Upgrading existing OS X installations to a newer version of the OS X

You can use createOSXinstallPkg to build an OS X installer which installs a stock copy of that version of OS X. However, you can also use createOSXinstallPkg to add your own packages to a createOSXinstallPkg-built OS X installer. This is important from my point of view because this ability allows me to add a package which can run various tasks during the first time the Mac boots following the OS upgrade’s completion, including the previously-mentioned automated Apple software update check and application of my shop’s preferred settings.

This kind of installer package is known as a firstboot installer package, and the tool that I’m using to build my firstboot package is First Boot Package Install Generator.app.

Once you have both createOSXinstallPkg and First Boot Package Install Generator.app available, here’s how you can create an OS X installer package that includes a firstboot package.

Preparing installers for use with First Boot Package Install Generator.app

1. Set up a folder to hold your installers.

Note: createOSXinstallPkg has an upper limit of 350 MBs of available space for added packages, though this can vary per OS X version. This is sufficient space for basic configuration, payload-free or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers to this installer.

2. Create numbered directories inside that folder, with 00 being the first and proceeding on to as many as you need. For numbers less than 10, make sure to label the directory with a leading zero (For example, 06).

3. Add one installer package to each numbered directory. The number of the directory indicates the install order, with 00 being the first.

Note: If installing more than 100 packages, be aware that this was beyond the scope of my testing. I recommend adding another leading zero where appropriate.

4. Once finished adding installers to the numbered directories, use First Boot Package Install Generator.app to generate a first boot installer package.

Creating the firstboot package using First Boot Package Install Generator.app

1. If needed, download the latest version of the First Boot Package Install Generator.app installer and install the application on your Mac.

2. Once downloaded and installed, double-click on the First Boot Package Install Generator application. You’ll be prompted to select the directory that contains the installers you want to have installed at first boot.

3. Once you’ve selected the folder with your installers, you’ll be prompted to name the installer package. By default, the name filled in will be First Boot Package Install, but this name can be changed as desired.

4. Once you’ve entered a name for the installer package, you’ll be prompted for a package identifier. By default, the name filled in will be com.github.first_boot, but this name should be changed to be something unique.

5. Once you’ve entered an identifier for the installer package, you’ll be prompted for a version number. By default, the value filled in will be 1.0, but this value can be changed as needed.

6. You will be prompted to choose if you want to have all available Apple software updates applied before your packages are installed. Choose Yes or No as appropriate.

7. Once the package name, package identifier, package version and software update choice have been set, First Boot Package Install Generator.app will prompt for an administrator’s username and password.

8. Once the admin username and password are provided, First Boot Package Install Generator.app will create the installer package and prompt you when it’s finished.

9. Click OK at the prompt and a new Finder window will open and display the newly-created first boot installer package.

10. Once the new package has been displayed, First Boot Package Install Generator.app will automatically exit. The package is now ready for use.

Building an OS X installer using createOSXinstallPkg

1. If needed, download the latest version of createOSXinstallPkg

2. Consult the createOSXinstallPkg documentation on how to create a new installer package that installs OS X El Capitan and includes a first boot package.

As an example of how I’m doing it, I’m running the following commands:

A. Open Terminal and navigate to the createOSXinstallPkg application directory

cd /path/to/createOSXinstallPkg

B. Create an El Capitan installer with the following options:

• Include one installer package named El Capitan First Boot Package Install.pkg
• Set the El Capitan installer package’s name to be El Capitan 10.11.1 Installer.pkg

sudo ./createOSXinstallPkg --source /path/to/Applications/Install\ OS\ X\ El\ Capitan.app --pkg /path/to/El\ Capitan\ First\ Boot\ Package\ Install.pkg --output /path/to/El\ Capitan\ 10.11.1\ Installer.pkg

Here’s what the output of the example process above looks like:

3. Once you have your OS X installer built, the next steps are to upload the createOSXinstallPkg-built OS X installer package to Casper and build your policies.

Installing OS X via Casper and Self Service

On Casper’s end, I have three policies that work together to run the OS upgrade process in Self Service. The first two policies have manual triggers:

cache-elcapitan-installer
run-elcapitan-installer

cache-elcapitan-installer goes with a policy named Cache El Capitan Installer which caches the createOSXInstallPkg-built El Capitan installer on the Mac in question.

run-elcapitan-installer goes with a policy named Install El Capitan Installer that installs the cached createOSXInstallPkg-built El Capitan installer

The third policy is named El Capitan Upgrade, which runs a script and is the only policy of the three which is visible in Self Service.

The script is available at the following location:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/

This script’s Parameter 4 and Parameter 5 correspond to the two following values:

• $4 – The amount of free space you want to require on the boot drive before the OS upgrade can proceed.
• $5 – the version number of the OS that is being upgraded to. For example, 10.11.

The reason I wrote a script to manage the OS upgrade process, as opposed to just installing the OS X installer package, is that I wanted to accomplish several things, but still ensure my users only had to deal with clicking the Install OS X button in Self Service.

Goals:

• Make sure the Mac has enough free space available for an OS upgrade, plus a little extra for insurance.
• Make sure that encrypted Macs were able to stop at the OS login window (to ensure that the post-upgrade processes I included would run normally.)
• Do everything possible to make sure that the OS installer could be run successfully.

Goal 1

I’ve set a minimum amount of free space available on the Mac being upgraded, which on my Casper server is configured to be 40 GBs (this is defined by the $4 parameter for the script.) This allows for the 8.8 GBs of free space needed as a bare minimum for OS X El Capitan’s system requirements, the 6 GBs of space taken up by the createOSXinstallPkg-built OS X installer package, then a generous safety margin.

To enforce this, the script checks the Mac being upgraded for the actual amount of free space available and compares it against the value which I’ve set as the minimum amount of free space available. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L10-L12

If a Mac does not have the specified amount of free space, a message appears to let them know that they need to have X amount of space to install the OS using Self Service and they have an amount of free space which is less than X. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L7

If they do have sufficient space available, a note is made in the log and and the script proceeds. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L14-15

Goal 2

To help make sure that both encrypted and not-encrypted Macs will stop at the OS login window for the running of the post-upgrade process, the script will check to see if the Mac is encrypted or isn’t. If it is, a setting is added to /Library/Preferences/com.apple.loginwindow.plist to disable FileVault 2’s automatic login. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L17-L42

As part of my post-upgrade process, I have a script that re-enables FileVault 2’s automatic login.

Goal 3

Once the script has gotten past the check for free space and the encryption check, a message appears to let the user know that the installer is downloading and that the Mac will automatically restart to begin the OS upgrade process. 

The parts of the script that handles these functions are linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L8

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L44

At that point, it downloads and caches the installer using the cache-elcapitan-installer policy. This is to ensure that all the parts of the OS installer downloaded properly before proceeding with the installation process. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L45

Once the cache-elcapitan-installer policy has completed, the run-elcapitan-installer policy runs and installs the cached installer. If the cached installer isn’t found, the policy fails but otherwise won’t cause problems. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L46

Once the run-elcapitan-installer policy completes, then the script triggers a restart. The part of the script that handles this is linked below:

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/Casper_Scripts/self_service_os_install/elcapitan/self_service_elcapitan_os_install.sh#L47

Once the Mac reboots, it will automatically proceed to upgrade the OS using the createOSXinstallPkg-built OS X installer.

Once the upgrade completes, the firstboot package’s process will be triggered and run the post-upgrade process.

As part of working with Automator to build applications, I’ve been leveraging the ability of Automator’s Ask for Finder Items action to set text prompts in my Automator-based applications.

These text prompts are included in the appropriate Finder windows and have been an easy way for me to set a particular message in an Automator selection window.

I recently noticed in OS X El Capitan that these messages no longer appear, which is a bit inconvenient as it leaves users of my applications with no clear direction as to what to do when this window appears.

It does not appear that AppleScript is affected by this issue, as the comparable AppleScript function properly displayed the desired text in both Yosemite and El Capitan.

As a workaround to keep my applications’ users informed on what to do, I’ve set standalone AppleScript notifications to appear in my Automator applications before the Ask for Finder Items Automator action’s window.

All three of my Automator-based applications have now been updated with the workaround:

• First Boot Package Install Generator.app
• Payload-Free Package Creator.app
• Simple Package Creator.app

I’ve filed a bug report with Apple on this issue. For those interested in duplicating this, it is bug ID 23688457. I’ve also cross-posted the bug report to Open Radar, so the bug report details are available from the link below:

https://openradar.appspot.com/23688457

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 contacts.app 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.

Downloading the application

Set Microsoft Outlook as default application for email calendars and contacts.app can be downloaded from the link below:

https://github.com/rtrouton/set_microsoft_outlook_as_default_application/releases/latest

System requirements

Set Microsoft Outlook as default application for email calendars and contacts.app has been tested and verified to run on the following versions of OS X:

• 10.9.x
• 10.10.x
• 10.11.x

Set Microsoft Outlook as default application for email calendars and contacts.app has been tested and verified that it does not run on the following version of OS X:

• 10.8.x
• 10.7.x

Not tested:

• 10.6.x or earlier

Using the application

1. Download a copy of the application if needed.

2. Unzip the application

3. Double-click on Set Microsoft Outlook as default application for email calendars and contacts.app

4. When prompted, click the OK or Cancel button:

• Clicking the OK button:
• This will set the newest version of Outlook on the Mac as the default application for email, contacts and calendars
• Clicking the Cancel button:
• Exits the application without making changes to the existing email, contacts or calendar settings.

5. If the OK button is clicked, the application will make changes to the email, contacts or calendar settings on the Mac to set Outlook as the default application for email, contacts and calendars.

6. Once the settings changes have been made, the application will notify you that Outlook has been set as the default application for email, contacts and calendars.

7. Click the Done button to exit the application.

Components

All components, icons and scripts needed to build the Automator application are available from the following location on GitHub:

https://github.com/rtrouton/set_microsoft_outlook_as_default_application

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.

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
1234567890
V2ZMQT6556P8WMH38MTQ6YSM8UXCCRYQ5MDS4WJGLKMP7RGSWECBCMT77556P8WCE8KMTQ6YSMNXJCCRYQ59MD9WJGLKMCSESSWECBCMB76556P8WCU3NMTQ6YSMLUYCCRYQ5MET8WJGLKMPSMJSWECBCM57F556P8WCU3CMTQ6YSM9DECCRYQ59XSCWJGLKMPNE9SWECBCMB79556P8WCH8KMTQ6YSMDXECCRYQ5MTSMWJGLKMPYRMSWECBCB7W7556P8W

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.

For my post-installation licensing, I’ve developed a script that does the following:

1. Checks for the presence of an existing .license.dat file in /Applications/Endnote X7.
2. If an existing .license.dat file is found, it is removed from /Applications/Endnote X7.
3. A new .license.dat is created with the data from my shop’s .license.dat file and stored in /Applications/Endnote X7.
4. The permissions on the new .license.dat file are changed so that it is read-write only by the license file’s owner. If this script is run with root privileges, the owner will be root.

The script is available below.

The script is also available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/set_endnote_7_volume_license

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:

http://www.openradar.me/23853195

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

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.

Compatibility:

This script has been tested on the following Linux distributions:

• Red Hat Enterprise Linux 6.x
• CentOS 6.x

Script location:

The scripts are stored in /scripts on both my Casper production and Casper test servers. I created this directory, you can use whatever directory you prefer.

Crontab:

The following entry has been added to the root crontab in order to send a daily report at 10:00 PM

0 22 * * * /scripts/casper_server_report.sh 2>&1 >> /dev/null

Permissions for the scripts:

Change permissions on casper_server_report.sh to match the following:

Owner – root (r/w/x)
Group – wheel (r/x)
Everyone (r/x)

The script is available below. It is also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/casper_server_report

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

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.

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.

The issue is that the listed OS version for the VM is changed to Other (32-bit) during the transfer process, which seems to change the boot support which VMware ESXi provides to the VM. To fix this, please use the procedure shown below.

1. If needed, launch VMware Fusion 8.x Professional and connect to the ESXi server in question
2. Make sure the affected ESXi-hosted OS X VM is powered off
3. Open the VM settings for the affected ESXi-hosted OS X VM
4. Click on General

5. In the General settings, verify that the VM is set to Other (32-bit)

6. Click on Other (32-bit) and change the OS to Apple Mac OS X 10.10 (64-bit)

7. When prompted, click the Change button to confirm that the OS should be Apple Mac OS X 10.10 (64-bit)

8. Verify that the OS is now listed as Apple Mac OS X 10.10 (64-bit) in the General settings.

9. Close the VM settings
10. Power on the VM

The VM should now boot successfully.

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

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.

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

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.

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:

Disabled

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

Active

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

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_system_integrity_protection_status

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.

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:

System Integrity Protection status: Disabled

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

System Integrity Protection status: Active

If SIP has custom configurations, the script will return output similar to that shown below:

System Integrity Protection status: Active
Kext Signing: disabled
Filesystem Protections: disabled
NVRAM Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled

This script is designed to be generic and usable by most reporting systems. I have also updated the counterpart Casper Extension Attribute with this same functionality.

For those interested, the script is available below and also from on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/check_system_integrity_protection_status