foigus' Notes

Mostly OS X Admin Related

Trial by Fiery

To start, be sure to read “Printers Were Sent From Hell To Make Us Miserable“.

This post is going to focus on EFI’s Fiery RIP print drivers and what can be done to deploy them across a fleet of Macs. If that doesn’t make one want to tear their hair out, try this on for size–all the certificates signing Fiery driver packages expired on March 30, 2017. Much like other companies’ certificate expirations, this renders the packages unusable. Since Fiery driver packages are not simple packages that can be expanded and flattened to strip the signature, new packages will need to be downloaded from EFI.

The first step to obtaining the right drivers for a Fiery RIP-based printer is to determine the printer model and Fiery RIP print server model.  While it’s not essential to know the Fiery RIP print server model, it may be required to obtain the proper driver.  For this exercise I’m going to assume a Ricoh Pro C901 model printer.

The next step is to go to EFI’s Fiery RIP driver download webpage.  While it’s possible to download the print driver directly from the Fiery RIP rather than EFI, the driver there is likely out of date.  Once signed into the EFI download site, select the “Partner” (printer vendor) and “Printer/Press Model”.  Hopefully the next selection of the “Fiery Model and Version” will have only one option, however there is a possibility there may be multiple entries here–for this exercise, the Ricoh Pro C901 model printer has four “Fiery Model and Versions” listed:

RIP Revisions and Models

The options above break down as follows:

  • “E-41” and “E-81” are the model of the Fiery RIP
  • “1.0” and “1.1” are the revision of the Fiery RIP

Regarding the Fiery RIP model, it may require reaching out to a print vendor to determine which RIP model is installed.  Regarding the Fiery RIP revision, this is visible by accessing the RIP’s web interface in a browser by entering its hostname:

901c RIP Version Redacted

For this exercise I’m going to assume an E-41 RIP, version 1.0.

Next is OS choice–the current Fiery RIP drivers support Mac OS X 10.7 through macOS 10.12, so the most recent driver should be OK.

Finally is language choice–the EFI download page may offer options for Japanese, Simplified Chinese, and other languages. For this case we’ll use the “other” languages option, which includes English.

Note once the driver has been downloaded from EFI, it may be useful to be able to decode the driver from the disk image name. EFI’s driver disk images use the following pattern:


The disk image “Ricoh_E41_v1_0R_FD51_v1Cert.dmg” translates to:

  • Vendor: Ricoh
  • RIP Model: E41
  • RIP Version: 1.0
  • Language: Roman (currently German , English , Spanish , French , Italian, and Dutch)
    Other language codes might include “J” for Japanese, or “SC” for Simplified Chinese. Note Roman languages were formerly designated by letters, so “EFIGSD” was English, French, Italian, German, Spanish, and Dutch
  • Fiery Driver Major Version: 51
  • Driver Revision: 1
  • New certificate (the lack of a “Cert” would indicate the old, expired certificate)

Regarding getting these drivers installed, I have written an AutoPkg recipe for revision “FD50” Fiery drivers, which also appears to work for “FD51” drivers. While researching these drivers, I encountered a few things:

  • Revision FD50/FD51 drivers have an postinstall (installation) script that recognizes a command line installation
  • Revision FD50/FD51 drivers seem to have consistent postinstall scripts across all printer/RIP models
  • Revision FD50/FD51 drivers will skip installation of the Fiery Driver Updater if it doesn’t exist

My goal is to remove the Fiery Driver Updater and repack the package–I’ve posted the recipes here, and the workflow is as follows:

  • Navigate to EFI’s download page and download the appropriate driver–currently “FD50” and “FD51” drivers have been successfully tested.
  • Note the name of the disk image (e.g. “Ricoh_E41_v1_0R_FD51_v1Cert.dmg”) and confirm that it is indeed named for a “FD50” or “FD51” revision driver
  • Add my AutoPkg repo and then create a uniquely-named override for the pkg recipe, using the name of the disk image
autopkg repo-add foigus-recipes 
autopkg make-override GenericFieryFD50.pkg -n Ricoh_E41_v1_0R_FD51_v1Cert.pkg
  • Edit the override, setting the following suggested “Input” values:
    • NAME is the name of the downloaded disk image without “.dmg”, and adding “_No_Update” at the end of the name (e.g. “Ricoh_E41_v1_0R_FD51_v1Cert_No_Update”)
    • PACKAGE_ID should be “com.efi.DMG-Name-with-hyphens-substituted-for-underscores.pkg” since the PkgCreator processor doesn’t like underscores (e.g. “com.efi.Ricoh-E41-v1-0R-FD51-v1Cert.pkg”)
    • PACKAGE_VERSION of 1.$version, where $version is the digits after “FD” in the downloaded driver (e.g. “1.51”)
  • Run the recipe with the “-p” option pointing to the downloaded driver dmg:
$ autopkg run Ricoh_E41_v1_0R_FD51_v1Cert.pkg -p /path/to/Ricoh_E41_v1_0R_FD51_v1Cert.dmg 
Processing Ricoh_E41_v1_0R_FD51_v1Cert.pkg...

The following packages were built:
 Identifier Version Pkg Path 
 ---------- ------- -------- 
 com.efi.Ricoh-E41-v1-0R-FD51-v1Cert.pkg 1.51 /Users/admin/Library/AutoPkg/Cache/local.pkg.Ricoh_E41_v1_0R_FD51_v1Cert/Ricoh_E41_v1_0R_FD51_v1Cert_No_Update.pkg

The package output still acts like the original Fiery package, but if run from the command line installs silently and skips installing the Fiery Driver Updater (including the Fiery Driver Updater LaunchAgent). This recipe doesn’t attempt to make the Fiery package any less weird (it’s still a big postinstall script that goes at least two layers deep with “installer” installing other pkgs), but hopefully should provide a common repackaging route.


Adobe Package Expiration

Update, 3/9/2017: Adobe has posted another KBase article about this.  Notably Adobe has re-signed Lightroom 4, Lightroom 5, and Scout.  Thanks to Graham R Pugh for passing this article along.

Update, 11:30 a.m. CST, 2/24/2017: Adobe has posted a KBase article about this and how it relates to Acrobat. Thanks to Blake Garner for letting me know. I’ve used the information in that article to update the list of affected Acrobat package revisions.

On February 21, 2017 at 1:42 p.m. CST a certificate used to sign some of Adobe’s older software titles expired. This causes some Adobe packages to fail–specifically packages that are, at their core, Apple-standard packages. These titles include the following:

  • Acrobat Pro DC Classic updates before 15.006.30198 15.006.30173
  • Acrobat Pro DC Continuous updates before 15.017.20050 15.016.20041
  • Acrobat Pro XI updates before 11.0.17
  • Acrobat Reader DC Classic updates before 15.006.30172
  • Acrobat Reader DC Continuous updates before 15.016.20039
  • Acrobat Reader XI updates before 11.0.17
  • Edge Code .98
  • Edge Inspect 1.5.486
  • Edge Reflow .51
  • Lightroom 5
  • Muse CC 2014.2.1
  • Muse CC 2014.3.2.11
  • Scout 1.1.3

While administrators may not intentionally be installing the non-Acrobat titles any more, there definitely can be forgotten titles included in long-ago created Creative Cloud Packager (CCP) packages. If macOS rejects a package due to an expired signing certificate, it will cause the entire CCP package to fail and no software will be installed.

Curiously the Acrobat packages newer than the above affected versions are signed with the same expired certificate as the earlier packages, but still pass macOS’s security muster. It is unknown why this is the case.

Rejected Adobe signing certificate:


Accepted Adobe signing certificate:


Apple packages embedded in a CCP package can be found with “find”:

$ find "lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents" -name "*.pkg"
lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg

Once found, the embedded packages can be checked one of two ways:

  • By opening the embedded package in Installer and clicking the (sometimes invisible) padlock in the upper right-hand corner. Problematic packages will have their certificate marked as “This certificate has expired” (pictured above with the Acrobat Pro XI 11.0.10 Updater)
  • By using the “pkgutil –check-signature” command. Problematic packages will be noted as “Status: signed by a certificate that has since expired” rather than “Status: signed by a certificate trusted by Mac OS X”:
$ pkgutil --check-signature "lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: signed by a certificate that has since expired
 Certificate Chain:
 1. Developer ID Installer: Adobe Systems, Inc.
 SHA1 fingerprint: 9D 75 C9 20 01 4A 65 04 94 A7 63 95 E3 91 93 47 04 E8 57 DF
 2. Developer ID Certification Authority
 SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
 3. Apple Root CA
 SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

I believe Adobe’s response to this issue will be one of the following:

  • “Do not use the affected packages. They are old and have been supplanted by newer technology.”  This response works for Scout, Edge Code, and other non-Acrobat packages
  • “Migrate to the newest version of the affected software.” This response works for Acrobat and Lightroom packages

Options to handle this issue include:

To expand and flatten a package to remove the digital signature:

  • First let’s verify the package doesn’t install properly
$ sudo installer -pkg "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg" -target / 
installer: Package name is lightroom_5_namedlicense
installer: Installing at base path /
installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
  • Then locate the embedded Apple package using the “find” command above
$ find "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents" -iname "*.pkg"
/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg
  • And we can verify the signature is expired
$ pkgutil --check-signature "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: signed by a certificate that has since expired
 Certificate Chain:
 1. Developer ID Installer: Adobe Systems, Inc.
 SHA1 fingerprint: 9D 75 C9 20 01 4A 65 04 94 A7 63 95 E3 91 93 47 04 E8 57 DF
 2. Developer ID Certification Authority
 SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
 3. Apple Root CA
 SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

  • We can use “pkgutil” to “expand” the package
$ pkgutil --expand "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg" "/tmp/Adobe Photoshop Lightroom 5.pkg"
  • And delete the original, expired package
$ rm -rf "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
  • “Flatten” the expanded package with “pkgutil” back to the location of the original
$ pkgutil --flatten "/tmp/Adobe Photoshop Lightroom 5.pkg" "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
  • We can now check the embedded package is no longer signed
$ pkgutil --check-signature "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg/Contents/Resources/Setup/LTRM5.6en_US/Adobe Photoshop Lightroom 5.pkg"
Package "Adobe Photoshop Lightroom 5.pkg":
 Status: no signature
  • Then test the edited package
$ sudo installer -pkg "/Users/admin/Desktop/lightroom_5_namedlicense/Build/lightroom_5_namedlicense_Install.pkg" -target / 
installer: Package name is lightroom_5_namedlicense
installer: Installing at base path /
installer: The install was successful.

Something in the AIR – AIR 20, 64 bit, and AIR Applications

Recently I was asked to deploy an updated Adobe AIR-based application.  I asked the requestor if they’d like the most current version of AIR (version to go along with it and the response was “Sure”.  I installed the application and imported it into Munki with a straightforward munkiimport of the application itself.

Later in the day I received a call back from the requestor letting me know the newly updated application crashed instantly upon launch.  Digging further, I discovered that when the application was launched, the following happened:

  • Air Application
    was renamed to
    Air Application_32
  • A new Air Application was generated

Upon further examination, this appears to be a result of AIR 20 becoming a 64-bit runtime.  An Adobe support article (Issues while downgrading from AIR 20 to a lower version on Mac OS X) says the following:

After you install AIR 20, any previously installed AIR app using the Shared Runtime that is launched gets updated. So the app’s launcher code will now be a 64-bit binary. The previously used 32-bit launcher gets renamed with a ‘_32’ suffix.

This provides an interesting issue for system administrators:

  • The bit architecture of an AIR application is a reflection of the version of AIR (either pre-AIR 20 or AIR 20 and beyond) that was installed when the AIR application was installed if the application was installed from an “.air” archive. Note an “.air” archive requires AIR to manually be installed on the target computer before installation of the “.air” archive
  • The bit architecture of an AIR application is a reflection of the developer’s computer used to package the AIR application if the application was a “Native Installer”.  Note a Native Installer can include AIR
  • If the installed version of AIR is upgraded from a previous version of AIR to AIR 20, an existing AIR-based application will attempt to generate a 64-bit executable in the “MacOS” directory
  • The default POSIX permissions of the “MacOS” directory of an AIR-based application are 755 (i.e. only the owner can modify the directory) and the default POSIX ownership of an AIR-based application is either root:admin (if a Native Installer was used and no version of AIR was previously installed) or the default user and group of the user who installed the application.  These do not work well in a managed environment
  • If the application cannot rewrite its executable, it may prompt for administrative rights (and refuse to run without them) or just crash (I’ve seen both)

Previously-distributed AIR applications that may have functioned normally under AIR 19 may not initially run properly with AIR 20.  Options to handle AIR 20 might include:

  • Repackaging 64-bit versions of AIR-based applications.  These would need to be generated by installing AIR 20, running a 32-bit AIR-based application, and then capturing and repackaging the resulting application
  • Reinstalling AIR-based applications following the installation of AIR 20, however this will only work for .air-archive based installations
  • Giving users write permission to the “MacOS” directory for all AIR-based applications, however this is a last resort

Also notable is that applications repackaged on a computer with AIR 20 may not function properly on computers where an earlier version of AIR is installed.  This is due to the 64-bit executable being packaged under AIR 20 and being distributed to a computer with an earlier 32-bit version of AIR.

To determine what architecture an executable is, use the “file” command:

$ file /Applications/Zinio\ Reader\\ Reader\ 4 
/Applications/Zinio Reader Reader 4: Mach-O 64-bit executable x86_64

Ensure AIR-based applications are 64-bit ready so they continue to work when AIR 20 is installed.

Packaging Adobe Rapid Release Updates With CCP or AAMEE

Recently I was presented with an Adobe Rapid Release update and requested to install it on a handful of computers.  Adobe’s Rapid Release program provides access to betas and hotfixes for Adobe products (as opposed to a rapid release schedule such as Firefox’s).  Rapid Release installers:

The Rapid Release update was provided on a dmg in a double-clickable “” format, which doesn’t play well with software distribution systems.  Since the Rapid Release update isn’t available through any of the normal channels, I reached out to Adobe_ITToolkit via Twitter and asked what I could do with the update.  The response was:

If it is an update to an existing major version it should work via the Offline media workflow.

The “Offline Media” workflow is generally intended for situations where bandwidth is limited, but in this case it can be used to package updates that would otherwise not be available.  The procedure to package the update:


  • Disconnect the computer where AAMEE is installed from the Internet (see note following step 15 on page 34, which explains that preference will always be given to updates from the Internet)
  • Open AAMEE
  • Click “New Update Package”
  • Give the package a name and a location to be saved
  • The check for updates will fail (“The update server is not responding”)–click “Continue”
  • Click “Add Update”
  • Navigate to the update dmg and click “Open”
  • Proceed normally with packaging the update


  • Open CCP
  • Navigate to the point where “Applications & Updates” are offered (there’s so many different workflows to reach this point I doubt I can cover them all)
  • Click “Add Offline Media”
  • Click the folder icon to browse for the update dmg
  • Navigate to the parent folder for the update dmg and click “Open” (No, the dmg is not directly selectable. No, I don’t know why)
  • Click “Extract”
  • Confirm the desired update appears in the lower portion of the “Add Offline Media” window and is checked
  • Click “Done”
  • Confirm the desired update appears in the “Applications & Updates” list and is checked (note this may require clicking “Show archived versions”)
  • Proceed normally with packaging the update

Then import the AAMEE/CCP pkg into your favorite software distribution system and install.

Thanks to the folks behind the Adobe_ITToolkit Twitter account for pointing me in the right direction.

ChoiceChangesXML and Office 2011

A post I wrote in JAMFNation that probably could have been it’s own blog post.  However fit in pretty well to the thread there–take a look.

SMB2 and 3 Enrichment Reading

Ever since Apple announced they were replacing Apple Filing Protocol (AFP) with Server Message Block (SMB) as the default file sharing language in OS X 10.9 “Mavericks” and beyond, Mac admins have had a love and hate relationship with trying to get SMB working in their environment.  A love of not having to be the odd man out in the file sharing world, and a hate of trying to make SMB perform as reliably as the well-worn AFP.  If your environment is supporting Macs that use SMB servers, a handful of links should be enlightening (and required) reading regarding why performance issues exist.  While these links alone won’t fix issues, they will provide insight into what’s going on:

If your current file sharing vendor doesn’t support a feature like “vfs_fruit” (the last bullet above), use the above links to write a feature request for your vendor.  In our case, we submitted a NetApp feature request (FPVR-00046972, feel free to add the voice of your organization!) to implement the “AAPL” SMB2 Create Context as discussed in the SMB2 source for OS X 10.9 Mavericks and OS X 10.10 Yosemite.

Disabling Java 8 Sponsor Offer Installation

Oracle Java 8u40 for OS X includes a new, unwanted payload–for those who aren’t paying attention, clicking right through the installation means the toolbar is now installed on their computer.  Oracle does offer a support page which details installing Java 8u40 without the toolbar, but the options boil down to two techniques:

  1. Install Java first so sponsor offers can be disabled though the Java Control Panel
  2. Use the command line and pass in the appropriate argument

#1 is kinda silly (installing software just to access a setting seems a bit unusual), and while #2 isn’t so bad it’s not the path the Java 8 updater wants to take you.  The Java 8 updater happily reattempts to install the sponsor offers.  So let’s say there are users with admin rights in your organization who theoretically could update or reinstall Java 8, how can we prevent sponsor offers on their computers?  Using fseventer, let’s see what files are modified when technique #1 above is applied:

defaults read ~/Library/Preferences/

 "/com/oracle/javadeployment/" = {
 "deployment.modified.timestamp" = 1426392515218;
 "deployment.version" = 8;
 "install.disable.sponsor.offers" = true;

defaults read ~/Library/Application\ Support/JREInstaller/ThirdParty.plist


cat ~/Library/Application\ Support/Oracle/Java/Deployment/
#Sat Mar 14 21:11:41 PDT 2015
#Java Deployment jre's
#Sat Mar 14 21:11:41 PDT 2015
deployment.javaws.jre.0.osname=Mac OS X
deployment.javaws.jre.0.path=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java

Beyond this, there are mentions across the Internet of placing the following lines in the system’s


However in my testing, currently the only file that matters is ThirdParty.plist, and the Oracle Java 8 installer only (per opensnoop) looks in the user’s home for this file:

  501    209 cfprefsd       4 /Users/admin/Library/Preferences/ 
  501    851 MacJREInstaller  -1 /Users/admin/Library/Autosave Information/Oracle.MacJREInstaller.plist 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt 
  501    851 MacJREInstaller  -1 /Users/admin/Library/Application Support/JREInstaller/ThirdParty.plist 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt 
  501    851 MacJREInstaller  27 /.vol/16777218/185166 
  501    851 MacJREInstaller  27 /Users/admin/Library/Application Support/JREInstaller/JREInstallLog.txt

Setting any or all of the above files except ThirdParty.plist and the sponsor offers are still offered.  ThirdParty.plist can be set with the following command:

defaults write ~/Library/Application\ Support/JREInstaller/ThirdParty SPONSORS -string "0"

run via a LaunchAgent, Outset, or some equivalent method.  Once ThirdParty.plist is set, future GUI installations of Java 8 will completely skip the sponsor offers step and immediately install Java.  Of course, keep in mind this all could change with the next release of Java.

Thanks to Johannes Seitz for researching the situation.  I was working on this so late at night I don’t recall whether Johannes originally wrote the above command or if I did (or maybe we both reached the same conclusion).  Cheers Johannes!

Outlook 2011 Folder Item Count Recommendations

Recently a user asked what the limits were for good performance in Outlook 2011.  Checking around the various support articles I found (italics mine):

So the number of items is in question and also whether or not subfolders count toward that number.  I contacted Microsoft support and asked which answers were correct–here is the response:

  • “I would recommend keeping the Inbox, Sent and Deleted items folders below 10,000 items if possible.”
  • “Keep a maximum of 20,000 items each in the Inbox and Sent Items folders (includes the folders and subfolders).”
  • “The Calendar, Contacts and Tasks should stay below 5,000 if possible.”

Note that these recommendations were easier for Microsoft support since my company uses Office 365 Hosted Exchange and thus the Exchange environment was known by support.  Different Exchange servers may not be able to support this sort of load and may require lower item counts.

Managing Java 7 and 8 Updates

Controlling your Caffeination Level
As part of improving software deployment at my organization, I tackled managing the Java 7 and 8 updater.  There’s a lack of Mac-based examples for this process (many thanks to Tim Sutton for his posts here and here, JAMF Nation-ites for this post, and Grivet-Tools for this post), so this is my contribution. The configuration file format for Java 7 is documented here and for Java 8 is documented here.  There are a pair of files:

  • deployment.config: Located at /Library/Application Support/Oracle/Java/Deployment/deployment.config, this file tells Java where to find the file (discussed below) and whether or not the file is mandatory.  If the file is mandatory and cannot be found, no Java software will be allowed to run.
  • A file listing various Java settings and optionally locking those settings.  Note that due to Safari sandboxing restrictions, must be located under /Library/Application Support in order for the Java plugin running inside Safari to access it (unless the Java plugin is running in Unsafe Mode).  A huge thanks to Michael Lynn (who goes by the IRC nickname “frogor” in the discussion about this restriction) for assistance with determining this requirement.

My deployment.config and files are below. First, deployment.config:

  • #deployment.config is a comment, and thus ignored
  • deployment.system.config details where the file can be found
  • deployment.system.config.mandatory=true tells Java the file is required.  If isn’t available Java code will not be executed

And then
  • is a comment, and thus ignored
  • deployment.macosx.check.update=false causes Java to not check for updates when the Java browser plugin runs.  However note the LaunchAgent-based background updater still checks for updates (we’ll handle that later)
  • deployment.macosx.check.update.locked prevents changing the deployment.macosx.check.update setting
  • deployment.expiration.check.enabled=false tells Java to not check to see if the current version of Java is expired.  Note Java has two expiration dates–one expiration date is the date of the next planned release (currently quarterly) if the computer can reach the Internet, while the second expiration date is 30 days after the next planned release date.  For example expiration dates, see the “Java Expiration Date” sections of the Java 8 Release Highlights
  • deployment.expiration.check.enabled.locked prevents changes to the deployment.expiration.check.enabled setting
  • sets the default Java security level to medium, but note the security level “medium” only exists with Java versions earlier than Java 8u20 (where the default security level was changed to “high”).  More details about Java security levels are located in the “Security levels in the Java Control Panel” section of this Oracle support page
  • prevents changes to the setting

But wait, there’s more!
In addition to the expiration and update checks that occur when running a Java applet in a browser, there also is an LaunchAgent-invoked background Java updater (the LaunchAgent job is located at /Library/LaunchAgents/ that will periodically check for Java updates and prompt for an update if one is available.  Unfortunately this prompt is shown to users who cannot actually install the Java update.  This automatic update check can be disabled with the following:

sudo defaults write /Library/Preferences/ JavaAutoUpdateEnabled -bool false

It’s very tempting to try to set this preference via a management system, however I did not have success with any of the following methods:

It appears the preference must literally be set in /Library/Preferences/ or it’s ignored.  Thankfully it’s easy to check to see whether this preference is set properly by setting the Java plugin to run in debug mode and then invoke the updater by hand:


/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java\\ Updater -bgcheck
2015-02-18 21:50:26.053 Java Updater[886:21122] Java Update Check is disabled

The Hits Just Keep on Coming
While testing this article, another settings file kept appearing at ~/Library/Preferences/ This file has very interesting looking keys:

$ defaults read /Users/admin/Library/Preferences/
 "/com/oracle/javadeployment/" = {
 "deployment.expiration.check.enabled" = false;
 "deployment.macosx.check.update" = false;
 "deployment.modified.timestamp" = 1424322701333;
 "" = MEDIUM;
 "deployment.version" = "7.21";

A simple way to set these preferences? Alas, no. It appears that Java treats this file as a cache, generated from Once I started testing whether just was enough to manage these settings, I discovered when I ran the Java plugin it reacted by wiping out most of the preferences in this file. There is one exception I could find. It appears that deployment.expiration.check.enabled is consulted from this file first, before  I noticed this because of the following scenario:

  • Install proper and deployment.config files
  • Install Java
  • Set the computer’s clock forward six months (thus Java was months beyond both expiration dates of the plugin)
  • Run the Java plugin in Safari
  • Be prompted the Java plugin had expired
  • Quit Safari
  • Run the Java plugin in Safari again
  • See no prompt the Java plugin had expired

This scenario does react to the initial setting of deployment.expiration.check.enabled in, however it will be subsequently overwritten by the setting in  This behavior is possibly part of the “native cache” Oracle mentions in this statement regarding deployment.expiration.check.enabled:

Note: To ensure that the expiration check is disabled, use the -userConfig deployment.expiration.check.enabled false option with the javaws command. If this property is changed in the file, open the Java Control Panel before starting an application to ensure that the native cache is synchronized with the file. Otherwise, the change might be ignored the first time an application is started.

Amusingly deployment.expiration.check.enabled can be handled properly via a Profile, however it should also be set in

After all of this, if the following is done:

  • Set settings via deployment.config and
  • Disable the background updater by writing a preference to /Library/Preferences/
  • Disable plugin expiration in (via a Profile or equivalent method)

Java should function even past expiration, however:

The easiest way to test all of the above is to download and install an out-of-date version of Java (so the security and expiration prompts will appear) and test these settings.  Note testing how Java 8 reacts to being expired is more difficult since the lowest security level (“high”) requires signed Java applets and successful validation of those signatures, thus it’s not possible to move the computer’s clock forward six months and have those signatures successfully validate.  In this case, make sure to test against a version of Java 8 that is old enough to be past the “secondary [expiration] mechanism” per the release notes.

More Thoughts on Munki’s AutoRemove

Previously I had discussed using autoremove for Adobe CC 2014 Installer Items, believing the best option to conserve disk space was to automatically remove Adobe CC since “Hey, if I didn’t put it there, it’s not needed.”  A couple of recent experiences has changed my mind.

  • I recently installed the Adobe CC 2014 suite on a computer where some Adobe CC 2014 applications were already installed.  While the client’s manifest was set up properly, I use the “site_default” manifest as a starting point to configure a handful of settings.  Unfortunately I chose to include the “production” catalog in the “site_default” manifest.  Since “site_default” (naturally) doesn’t include any Adobe CC 2014 products, Munki checked software for removal and attempted to remove the Adobe CC 2014 software it discovered.  In order to prevent future unintended actions, I created a separate “site-default-catalog” catalog for the “site_default” manifest, thus lowering the chance I shoot myself in the foot.*
  • Both the “old” CS6 suite and the “new” Adobe CC 2014 suite include the now-discontinued Fireworks CS6. I had both Fireworks CS6 packaged by AAMEE (licensed via ETLA) and Fireworks CS6 packaged by CCP (licensed via Creative Cloud) available in my Munki repo as unique Installer Items. I then installed Fireworks CS6 from the AAMEE-based Installer Item.  On the next managedsoftwareupdate run Munki noticed Fireworks CS6 was installed and the Fireworks CS6 Installer Item from the CCP-based installer was not included in the client’s manifest and therefore should be removed. Thus Munki had it’s own titanic battle with itself, alternately uninstalling and reinstalling Fireworks CS6 with each subsequent managedsoftwareupdate run.

*Note I didn’t say Munki succeeded in uninstalling the CC 2014 software.  Since I was still testing Munki 2.1’s support of CCP pkgs, I hadn’t yet made Munki 2.1 available in the “production” catalog.  Thus the CCP Installer Item’s uninstall_method of “AdobeCCPUninstaller” wasn’t understood by the older Munki client and uninstall failed.

Due to the two items above I’ve decided that setting “autoremove” to true for Adobe CC 2014 isn’t the best choice.  I’ve pared back my “autoremove” to the serialization Installer Items rather than the Adobe CC 2014 Installer Items themselves.