foigus' Notes

Mostly OS X Admin Related

Determining Creative Cloud for Enterprise Serial Number Expiration Dates

Yesterday in #adobe on MacAdmins Slack, Nate Felton asked the following question about what he sees on the Adobe Licensing Website:


Which led to a discussion of why one serial number was better than the other, including asking “How does one know when their Creative Cloud Enterprise serial number is going to expire?” For those with sufficient rights to the Adobe Licensing Website, the code (for example “SN184”) is available there:


But what this code meant was unclear.  A couple of quick searches led to this post by Alister Black on Adobe’s discussion forums:

> So the SN184 key expires in (April?) 2018?

Q4 2018

This caused me to reach out to our Adobe rep for clarification:

> For colleagues who have serial numbers such as SN194, SN201,
> SN213–those would be Q4 2019, Q1 2020, and Q3 2021,
> correct?

Yes. And note that our FY begins on December 1st. SN194 = November 30, 2019

Serial numbers designated in the licensing website with a “SNYYQ” designation expire at the end of the quarter designated by “Q” and the year that ends with the last two digits designated by “YY”, keeping in mind that quarters are calculated using Adobe’s fiscal year which starts on December 1.

If the currently-installed serial number will soon expire, users will be notified with a warning similar to this (thanks to Chris Helming on MacAdmins Slack for the screenshot):


Also note it seems to be a rule of thumb that serial numbers expire about one year after the end of the Creative Cloud for Enterprise agreement, which seems to be a gracious amount of time to allow for a new agreement to be hammered out.


Blinded me with Silence: Adobe and the End of the Dolby License

Recently Adobe ended a licensing agreement with Dolby, “moving to native Operating System (OS) support for Dolby Digital decoding (reading Dolby files) and…no longer provid[es] support for encoding (writing) Dolby Digital and Dolby Digital Plus sound formats in the current and future releases of Creative Cloud.”  Adobe will now rely on native OS decoding of Dolby media for playback (supported by OS X 10.11+ or Windows 8.1+) and the ability to create Dolby media will be removed. As a result some versions of some Creative Cloud software titles are no longer available, and as of November 3, 2017 the following professional titles are affected:

  • After Effects CC 2015.3 and 2017
  • Audition CC 2014, 2015, 2015.2, and 2017
  • Media Encoder CC 2014, 2015, 2015.3, and 2017
  • Prelude CC 2014, 2015, 2015.4, and 2017
  • Premiere Pro CC 2014, 2015, 2015.3, and 2017

These titles are no longer available for Enterprise packaging via the Creative Cloud Packager or the Admin Console Cloud Packager. The CC 2017 versions of the applications do seem to be available via the Creative Cloud Desktop App (CCDA), however these CC 2017 titles appear to have been revised to no longer include Dolby software.

This change may create issues for customers–if a package for an appropriate version of a particular title has not been previously built (i.e. from either the Creative Cloud Packager or the Admin Console Cloud Packager), it may not be possible to install that software. This complicates both new installations (such as installing the software on additional computers) and reinstallation (such as during troubleshooting or computer rebuild situations). Beyond this, if the CCDA is used to install newer versions of software, the default setting is to remove previous versions of that software title. It is reasonable that a later version of a piece of software would be installed for testing, however if issues were discovered it would be impossible to reinstall the earlier version and be able to access the full features of that previous version.

Regarding software installation, if it’s not possible to build the software installation packages required by your organization the only option is to reach out to Adobe support and request assistance.

Also note that if it’s not possible to build an installation package for a title, it’s also not possible to build an uninstallation package for that title. There are a few options for uninstallation:

  • Software can be uninstalled by hand using the GUI uninstaller–although it doesn’t scale well, it is an option
  • If the original uninstallation package (created when the installation package was created) is available, this would also work to uninstall the software
  • If the title to be uninstalled uses a new-style “HyperDrive” package (“HyperDrive” package titles listed here) it is possible to uninstall the software via the command line
  • The CC Cleaner Tool may be used to generate an XML file to uninstall software using the CC Cleaner Tool binary. Note the CC Cleaner Tool is a command-line binary plus a configuration file that needs to be generated on a computer that has the software installed that is wished to be removed. The CC Cleaner Tool is not a traditional macOS installation package and will require being integrated into a package to be used with most management systems. Also note it appears it is not possible to silently uninstall “all” products and suppress the CC Cleaner Tool EULA–all products that are desired to be uninstalled will need to be noted in “cleanup.xml” in order to bypass the EULA
  • It may be possible to build a CCP “Uninstall ‘Package'” and modify the “AdobeCCUninstallerConfig.xml” configuration file to add additional products to uninstall. Note a CCP “Uninstall ‘Package'” is a command-line binary plus a generated configuration file–it is not a traditional macOS installation package and will require being integrated into a package to be used. Also note software installed using the older Adobe “RIBS”-based packages require “SapCode”, “Version”, “Leid”, “Platform”, “mediaSignature”, and “adobeCode” information in order to be successfully uninstalled. Obtaining this information will likely will require the assistance of Adobe support, and modifying a CCP “Uninstall ‘Package'” should be evaluated after trying the above CC Cleaner Tool option
  • It also may be possible to contact Adobe support and ask to be provided the proper uninstall package

These installation changes due to shifting licensing are unfortunate, since it shifts a potentially significant burden onto the IT administrator. Hopefully in the future Adobe’s licensing folks will work with the Enterprise IT folks in order to have a smoother transition with additional documentation.

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.