foigus' Notes

Mostly OS X Admin Related

Adobe Package Expiration

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:

acrobat_xi_pro_update_11-0-10_certificate

Accepted Adobe signing certificate:

acrobat_xi_pro_update_11-0-19_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 / 
Password:
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 / 
Password:
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 20.0.0.233) 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.app/Contents/MacOS/Air Application
    was renamed to
    Air Application.app/Contents/MacOS/Air Application_32
  • A new Air Application.app/Contents/MacOS/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\ 4.app/Contents/MacOS/Zinio\ Reader\ 4 
/Applications/Zinio Reader 4.app/Contents/MacOS/Zinio 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 “AdobePatchInstaller.app” 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:

For AAMEE

  • 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

For CCP

  • 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 ask.com 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.plist

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

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

{
  SPONSORS = 0;
}

cat ~/Library/Application\ Support/Oracle/Java/Deployment/deployment.properties

#deployment.properties
#Sat Mar 14 21:11:41 PDT 2015
deployment.modified.timestamp=1426392701602
deployment.version=8
install.disable.sponsor.offers=true
#Java Deployment jre's
#Sat Mar 14 21:11:41 PDT 2015
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.8
deployment.javaws.jre.0.osname=Mac OS X
deployment.javaws.jre.0.path=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
deployment.javaws.jre.0.product=1.8.0_40
deployment.javaws.jre.0.osarch=x86_64
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

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

install.disable.sponsor.offers=true
install.disable.sponsor.offers.locked

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/com.apple.HIToolbox.plist 
  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 deployment.properties file (discussed below) and whether or not the deployment.properties file is mandatory.  If the deployment.properties file is mandatory and cannot be found, no Java software will be allowed to run.
  • deployment.properties: A file listing various Java settings and optionally locking those settings.  Note that due to Safari sandboxing restrictions, deployment.properties 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 deployment.properties files are below. First, deployment.config:

#deployment.config
deployment.system.config=file:///Library/Application%20Support/Oracle/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true
  • #deployment.config is a comment, and thus ignored
  • deployment.system.config details where the deployment.properties file can be found
  • deployment.system.config.mandatory=true tells Java the deployment.properties file is required.  If deployment.properties isn’t available Java code will not be executed

And then deployment.properties:

#deployment.properties
deployment.macosx.check.update=false
deployment.macosx.check.update.locked
deployment.expiration.check.enabled=false
deployment.expiration.check.enabled.locked
deployment.security.level=MEDIUM
deployment.security.level.locked
  • #deployment.properties 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
  • deployment.security.level=MEDIUM 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
  • deployment.security.level.locked prevents changes to the deployment.security.level 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/com.oracle.java.Java-Updater.plist) 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/com.oracle.java.Java-Updater 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/com.oracle.java.Java-Updater.plist 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:

export JPI_PLUGIN2_DEBUG=1

/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/Java\ Updater.app/Contents/MacOS/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/com.oracle.javadeployment.plist. This file has very interesting looking keys:

$ defaults read /Users/admin/Library/Preferences/com.oracle.javadeployment
{
 "/com/oracle/javadeployment/" = {
 "deployment.expiration.check.enabled" = false;
 "deployment.macosx.check.update" = false;
 "deployment.modified.timestamp" = 1424322701333;
 "deployment.security.level" = 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 deployment.properties. Once I started testing whether just com.oracle.javadeployment.plist 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 deployment.properties.  I noticed this because of the following scenario:

  • Install proper deployment.properties 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 com.oracle.javadeployment.plist, however it will be subsequently overwritten by the setting in deployment.properties.  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 deployment.properties 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 deployment.properties.

Wrap-up
After all of this, if the following is done:

  • Set settings via deployment.config and deployment.properties
  • Disable the background updater by writing a preference to /Library/Preferences/com.oracle.java.Java-Updater.plist
  • Disable plugin expiration in com.oracle.javadeployment (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.

(Re)Activating T-Mobile Data for Life on a Replaced iPad

Over the last week I had a difficult time reactivating an iPad with T-Mobile’s Free Data for Life.  The iPad was originally set up with Free Data for Life around February, and it worked for the infrequent occasions I needed cellular data.  In order to not accidentally use the data, I turned off cellular data when I wasn’t actively and intentionally using cellular data. About five months ago the iPad was damaged and replaced under AppleCare+ and the T-Mobile SIM was transferred to the replacement iPad.

A week ago I enabled cellular data on the iPad and was unable to access the Internet, repeatedly being redirected to a page where I could purchase additional data.  It turns out that I hadn’t enabled cellular data since the iPad was replaced–not surprising the data plan wasn’t working since the replacement iPad was a different device than originally registered for the data.  However when I contacted T-Mobile support it didn’t seem they knew what to do when confronted with a replacement iPad.  T-Mobile support had me try at least the following, while repeatedly assuring me the account was ok:

  • Wait a few days for the IMEI to “update in the system”
  • Verify there was a T-Mobile signal
  • Verify there was no T-Mobile outage in the area
  • Reseat the SIM card
  • Verify the APN settings
  • Reset network settings
  • Enable Data Roaming
  • Reset the iPad back to factory settings (I refused to do this)
  • Attempt to re-register through t-mobile.com/connectme
  • Have T-Mobile support change the IMEI on file to match the replacement iPad’s IMEI
  • Reset Subscriber Services
  • Purchase a replacement SIM card and tried to self activate service (T-Mobile Twitter support credited the cost of the replacement SIM to my T-Mobile account)
  • Have T-Mobile support activate the replacement SIM and waited two hours
  • Multiple restarts of the iPad (after practically every step above)
  • Talk to (actually passed to) Apple Support (fortunately Apple was closed when this was tried)

The solution was to have T-Mobile support delete the existing Free Data for Life plan and service telephone number from their system and assign a new phone number (and no service plan) to the SIM and IMEI.  The iPad was then prompted to create or sign in with an existing T-Mobile ID (I used my existing ID).  Then I needed to pick a data plan:

  • “Always Connected”: Postpaid subscriptions of GB or MB of data a month
  • “Data on the Fly”: Data “packs” that expire after a period of time or when exhausted
  • “Plain and Simple”: No paid data

The “Plain and Simple” option is what I wanted, since that provides the monthly 200MB of free data without any contract or any billing relationship with T-Mobile at all.  Once I set up the new data “plan”, cellular data was once again working. If you’re considering using T-Mobile’s Free Data for Life plan, make sure you save certain information because it will be necessary if you have to talk to T-Mobile Support:

  • The T-Mobile ID (the email address used when the account was created)
  • The T-Mobile account password (although T-Mobile support never asked for this, it was necessary when signing into the T-Mobile account)
  • The phone number assigned to the iPad (available from the “View Account” button under the “Cellular Data” section of “Settings”
  • The account PIN (note this PIN is emailed to you upon successful registration, unfortunately I did not know that until after I had worked with T-Mobile Support to reset the PIN)
  • The SIM card number
  • The IMEI number of the iPad

Hopefully the issues I experienced getting T-Mobile service up and running on a replacement iPad were because I wasn’t a paying customer.  However I’d think the whole idea behind the Free Data for Life plan is to get T-Mobile’s SIM into as many iPads as possible, and difficulties like this make it hard to use T-Mobile’s service.