Flash Dance

In comments on my previous post here, TGB makes some interesting points:

While you’re not wrong that Flash Player deployment isn’t ideal, and it should be as easy as dragging and dropping a pkg, I don’t see how the repackaging route is any more of a waste of time than any other product. Adium, Mactracker, Firefox, Chrome and a whole bucket of other apps all require packaging to be deployed. Sure, they might auto-update, but you have to get an initial version out there, not to mention getting your preferred default settings out too.

Most, if not all the items mentioned (Adium, Mactracker, Firefox, and Chrome) are distributed as “drag-n-drop” disk images where the user is expected to drag the application to the /Applications folder. I’d argue that is an industry standard deployment method. The software deployment system I use (Munki) can install items like this without the need to package them. If your software deployment mechanism does not, perhaps you should be requesting that feature from your vendor, since this is a very common distribution format, and code-wise, requires  little effort to support. When a new version of Firefox or Chrome comes out, I just download the disk image and directly import it into Munki — no packaging needed.

Adobe Flayer Player cannot be distributed as a drag-n-drop application disk image — it’s not an application. So the “correct” distribution format for this software is the Apple package format.

Preferred default settings is a completely different issue. As long as vendors use Apple’s preference file format, this is solved with MCX or Lion/Mountain Lion profiles.

TGB also writes:

Not to mention, with any of these products, testing them (yes?) is more time and effort-intensive than any actual packaging. 3/4 of deployment and integration is non-technical work. A couple of minutes difference doesn’t really matter in the scheme of QA, UAT and change management process (or are others just not doing that?).

Flash is not needed by any business-critical application where I work, yet our users demand (or at least expect) it and Apple and Mozilla demand it stay up-to-date, or they will disable the plug-in. So for us at least, testing is quite minimal for Flash. If it installs and can display some Flash content, it’s good.

But yes, I do understand and sympathize with admins that must test each release of Flash with business-critical applications — and Adobe’s distribution format is not the key issue here; frequency of releases is. I’d argue that this is an impetus to reduce or eliminate your internal dependency on Flash.

Where I disagree with TGB: Adobe’s non-standard distribution adds more than a “couple of minutes” to preparing a new release of Flash for enterprise distribution. If we could be sure that Adobe will never change anything about their installer and updater, we could just figure out a process and repeat it for each new release. But Adobe can and has changed things, so for each release we must also test that our packaging/repackaging/custom deployment steps actually end up with the desired results. This is usually not a huge deal, but also cannot be ignored. But more importantly, theirs is a one-off solution. If we have to keep track of and test different deployment solutions for each vendor and product, we end up wasting a lot of time and effort, and making a lot of mistakes. Where would it end? Unique software deployment methods for each vendor? (Oh that there was only ONE unique deployment method for Adobe software!)

No, a line must be drawn. Here. No farther.

Flash Dance

Flash Mob

Flash Player 10
My recent posts on deploying Flash Player 11.3 and 11.4 have generated a lot of comments. Some frequent themes: “Why are you bothering with all this? Just deploy the embedded package and be done with it!” and “Just repackage it with PackageMaker/Composer/etc and push that package!” These are certainly valid approaches you might decide to use in your organization.

But I worry that the larger point is being missed.

By recommending and supporting a non-standard deployment mechanism, Adobe is forcing enterprise admins to make choices about how to deploy their software. Some of those choices break the auto-update mechanism. Some are cumbersome to implement. Even Adobe’s recommended solution has several failure modes. But most importantly, it creates more work for the admin, since Adobe’s Flash distribution is not deployable as-is.

This is a colossal waste of time in the aggregate. Not only do I have to waste time packaging, repackaging or otherwise wrapping or modifying the Flash installer in order to deploy it; I must do so for each new release of Flash. And so must thousands of other admins all over the world.

Worse, because of all the possible choices (and no clear winner among them), there’s going to be many different permutations of what gets installed and how. This lack of consistency is a real problem, and must create additional support burdens, not only for local support, but for Adobe itself, as Adobe can’t even count on what is installed. I’m sure Adobe would like to get new releases of Flash out there as fast as possible; their choices actually make that harder to accomplish.

The only real path out of this madness is for Adobe to adopt and support a standard software distribution mechanism on Mac OS X: Apple packages. Enterprise admins should be able to take a Flash Player package and import it into their software distribution system without additional modification.

Part of the issue here is that there appears to be two parts to Adobe Flash Player: the actual Flash plugin, and the auto-update mechanism. These appear to be developed by two different teams. The team developing the Flash plugin itself seems to be doing (mostly) the right thing — they ship the Flash Player plugin as an Apple package that works perfectly with enterprise deployment tools.

The team responsible for the updater, however, is using non-standard deployment tools, leaving us with a mess. Not only is the installation a problem, but the updater doesn’t work when no-one is logged in. This was a nasty problem with Flash Player 11.3; the “fix” in Flash Player 11.4 seems to be that the updater just refuses to run if no-one is logged in. Here’s hoping that’s a temporary/quick fix until the “real” fix is in.

Flash Mob

I’m renaming this blog to managingflash.wordpress.com

Managing Flash is even worse than it first appears.

Recent Safari updates now disable older versions of the Flash plugin. It wasn’t clear how “old” a version had to be to be disabled. Today I got an unwelcome surprise.

Most of our managed machines have Flash Player version installed. I was aware that version was available, but due to the issues here, I had not yet widely deployed it.

Today Adobe released Flash Player 11.4.402.265, and we started getting calls that Safari was blocking the Flash Plugin as out of date. Most of our users do not have admin rights, so we needed to fix it for them. I imported the Adobe Flash Player.pkg from the installer into Munki and tested an install on one machine. Flash was no longer blocked.

So I still don’t know exactly how old the Flash Player must be before Safari blocks it, but now we have to be even more proactive in keeping Flash up to date in our organizations.

All the more reason to hope that the issues with the auto-update feature have been addressed with the 11.4 release. The release notes are silent on this issue. More testing needed, apparently!

I’m renaming this blog to managingflash.wordpress.com

New topic: Flash Player 11.4

Flash Player 10
And here I thought I would be done writing about Flash Player for a while.

Today Adobe released Flash Player 11.4.402.265. If comments here are to be believed, this release fixes a bug that can occur when the auto-update process runs when nobody is logged in. It may be difficult to test until the next Flash update, however.

In last week’s post here, I outlined some of the issues with Adobe’s recommended “silent” install method for Flash Player:

  1. This “silent” install causes an icon to appear in the Dock as it runs.
  2. Executing this method as described by Adobe fails when the machine is at the loginwindow — the process hangs indefinitely.
  3. It turns out there is an “–uninstall” flag for Adobe Flash Player Install Manager, but it cannot be done silently; it always displays a confirmation dialog and a success/failure dialog.
  4. Uninstall is therefore impossible at the loginwindow, as the OS prevents display of the dialogs (not that you’d want to rely on people clicking on the dialogs anyway)

One more issue has since occurred to me: you cannot use this installation method to install Flash Player on anything other than the current startup volume. Therefore, there is no way to include Flash Player in a “compiled” image, such as one built with InstaDMG, Apple’s System Image Utility, or FileWave Lightning. It’s also not possible to use this method with a NetInstall image, or incorporate it into a package built with createOSXinstallPkg. And if you wanted to use this method with DeployStudio, you must do it as a “postponed” install; it will not work as a “live” install.

New topic: Flash Player 11.4

Yet Another Post on Flash Player 11.3

If you’ve decided to repackage Flash Player 11.3 in order to side-step some of the mass deployment issues, or if you want to write a script to remove/uninstall Flash Player, it’s helpful to have a list of what gets installed.

The Adobe Flash Player.pkg installs the following files:

/Library/Application Support/Adobe
/Library/Application Support/Adobe/Flash Player Install Manager
/Library/Application Support/Adobe/Flash Player Install Manager/fpsaud
/Library/Internet Plug-Ins/Flash Player.plugin.lzma
/Library/Internet Plug-Ins/flashplayer.xpt
/Library/PreferencePanes/Flash Player.prefPane
/Library/PreferencePanes/Flash Player.prefPane/Contents
/Library/PreferencePanes/Flash Player.prefPane/Contents/Info.plist
/Library/PreferencePanes/Flash Player.prefPane/Contents/MacOS
/Library/PreferencePanes/Flash Player.prefPane/Contents/MacOS/Flash Player
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/FlashPlayerPreferences.nib
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/FlashPlayerPreferences.png
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/FlashPlayerPreferences.searchTerms
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/InfoPlist.strings
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/minusSign.png
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/pencilIcon.png
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/plusSign.png
/Library/PreferencePanes/Flash Player.prefPane/Contents/Resources/version.plist

The /Library/Internet Plug-Ins/Flash Player.plugin.lzma file listed above is then expanded in the package postflight script (which is actually a binary executable instead of a script) into the /Library/Internet Plug-Ins/Flash Player.plugin bundle.

If you use Adobe’s recommended “silent” installation method, or just manually run the Install Adobe Flash Player.app, /Applications/Utilities/Adobe Flash Player Install Manager.app is also created.

So here’s a list of paths to either capture into a package if you are repackaging Flash Player, or to remove if you are trying to do a silent uninstall:

/Applications/Utilities/Adobe Flash Player Install Manager.app/
/Library/Application Support/Adobe/Flash Player Install Manager/
/Library/Internet Plug-Ins/Flash Player.plugin/
/Library/Internet Plug-Ins/flashplayer.xpt
/Library/PreferencePanes/Flash Player.prefPane/

Optionally, you might also want to remove:

/Library/Application Support/Macromedia/mms.cfg

Which contains the Flash Player auto-update settings.

Yet Another Post on Flash Player 11.3

More on Flash Player 11.3

Flash Player 10
Last Friday I posted on some issues with Adobe’s new recommended method for unattended installs of Flash Player 11.3.

You might be interested in exactly what “extra” things are installed when you use the Adobe method rather than just installing the Adobe Flash Player.pkg found inside the Install Adobe Flash Player.app bundle.

It turns out that after installing the package, the app copies itself (minus the embedded package) to /Applications/Utilities/Adobe Flash Player Install Manager.app.

When the Adobe Flash Player.pkg is not found inside the app bundle, launching the Adobe Flash Player Install Manager.app causes it to display the Flash Player uninstall UI.

The executable at /Applications/Utilities/Adobe\ Flash\ Player\ Install\ Manager.app/Contents/MacOS/Adobe\ Flash\ Player\ Install\ Manager is what is called when you click “Check Now” under Advanced->Updates in the Flash Player preference pane. If /Applications/Utilities/Adobe\ Flash\ Player\ Install\ Manager.app is missing, the preference pane crashes. This explains the issue which led us to look at Adobe’s recommended deployment mechanism.

Since checking for and downloading new Flash updates is handled by Adobe Flash Player Install Manager.app, it would seem that automatically checking for updates and auto-installs of any Flash Player updates are also broken on machines where Flash Player was installed via the package instead of via Adobe’s supported method, since this application will be missing.

More on Flash Player 11.3

Unattended installs of Flash Player 11.3

Flash Player 10
For some time now, OS X admins have been downloading the latest Flash Player disk image, opening the “Install Adobe Flash Player.app” application, pulling out the “Adobe Flash Player.pkg” package, and using that package to do unattended installs of Flash Player.

Recently, people have discovered an issue with that method: some component related to the Flash updater is not properly installed. If you use this installation method, open the “Flash Player” preferences pane in System Preferences, select the “Advanced” tab, and click “Check Now” under “Updates”, it crashes.

It turns out that Adobe has changed their recommended method for “silent” installs of Flash Player: see this article.

The method outlined in Adobe’s article works, and resolves the crashing issue in the Preferences pane, but there are several issues:

  1. This “silent” install causes an icon to appear in the Dock as it runs.
  2. Executing this method as described by Adobe fails when the machine is at the loginwindow — the process hangs indefinitely.
  3. It turns out there is an “–uninstall” flag for Adobe Flash Player Install Manager, but it cannot be done silently; it always displays a confirmation dialog and a success/failure dialog.
  4. Uninstall is therefore impossible at the loginwindow, as the OS prevents display of the dialogs (not that you’d want to rely on people clicking on the dialogs anyway)

We can fix (or at least work around) issues 1 and 2.

Continue reading “Unattended installs of Flash Player 11.3”

Unattended installs of Flash Player 11.3

Disabling Auto Update notifications for Flash Player 10.3

Flash Player 10Flash Player 10.3 introduces auto-update notifications for Mac OS X. If you’d like to disable those for your managed clients (because you are distributing these updates via munki, for example), install this package:


This package installs a file at /Library/Application Support/Macromedia/mms.cfg with the following contents:


More info here:


Thanks to Patrick Fergus for the tip.

Update 02 July 2012: updated the link for the package.

Disabling Auto Update notifications for Flash Player 10.3

More Help from Adobe

Image for Adobe HelpAdobe Community Help Client 3.5 for the Adobe CS5 apps has been released:


However, like prior releases, Adobe doesn’t make it easy to deploy. Fortunately, this technique still works.

You’ll need:
The package wrapper.
The updated Adobe AIR Installer. Make sure to extract it from the disk image before adding it to the package wrapper.
The updated AdobeHelp.air app. (Adobe doesn’t make that easy to find!)

Follow the instructions from the prior post, and don’t forget to bump the CFBundleShortVersionString in the Info.plist to “”.

Good luck!

Updated on 02 July 2012 with a new link to the package wrapper.

More Help from Adobe

Updating Adobe Help for CS5

Image for Adobe Help
Adobe recently released an update for their Adobe Help client for Adobe CS5 products. It’s an Adobe AIR-based application, and so is packaged in a different format than Adobe CS5 products or CS5 updates, so enterprise deployment software that knows how to deal with other Adobe software may still not be able to deploy this update.

So what’s a poor Mac OS X admin to do?
Continue reading “Updating Adobe Help for CS5”

Updating Adobe Help for CS5