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.
Managing OS X 
Hello, I’m a member of the Flash Player team and wanted to thank both you and everyone who’s commented for the feedback given. I think you’ll find that our team is for reducing the amount of work required by admins when deploying Flash Player, though at times we might need to be made aware (or reminded) of the pain points.
I always recommend users frustrated, impeded, or blocked with the runtime take a minute and add a bug to our bug database (http://bugbase.adobe.com), then publicize the bug url so that others in the community can add comments and votes. These reports are scrutinized very closely. I’d also encourage you to visit our forums at http://adobe.ly/oYQRZZ to post issues or you can reach out to me directly at ccampbel@adobe.com.
We’ve recently implemented a way for customers that have signed our distribution agreement to leverage our silent auto update service using their own internal servers. If you haven’t seen this, I encourage you to take a look at page 19 of our 11.4 admin guide (http://adobe.ly/QQ9z9) and the section titled “Background updates from an internal server”. While this isn’t a standardized system, we do hope this improves your workflow and we welcome your feedback.
Hi Chris, thanks for taking the time to post on Greg’s blog.
With all due respect, we are only interested in getting proper PKG installers for zero-touch deployment. We are perfectly content with Adobe Flash Player updating via internet. Let’s not take our eye off the ball. 😉
You guys have a very well designed Flash Player.pkg installer buried in a horrid Install Adobe Flash Player.app application. What’s up with that? ” 🙂
Give us a proper PKG installer and you’ll be our hero.
Don Montalvo, TX
And please don’t forget that the .pkg installer must also work if there’s no user logged in!
Chris, as Patrick stated, zero-touch is essential for enterprise deployment. The command in “Adobe Flash Player Administration Guide for Flash Player 11.4” does not work without a user being logged in:
$ sudo /Volumes/Flash\ Player/Install\ Adobe\ Flash\ Player.app/Contents/MacOS/Adobe\ Flash\ Player\ Install\ Manager -install
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
Vendor-supplied DMGs are standard for distribution, however they are not standard for deployment. Distribution and deployment should not be confused, because they are not the same thing. Any DMG can have any kind of content aside from the single .app application. You throw that into Casper and you won’t get anywhere. Maybe Munki is different. However, any shortcut you’re getting is Munki-specific.
Default settings are part of deployment. They simply are. That’s part of what we do – making sure software deploys in a ready-to-use state. If you just throw software at machines in an un-configured state, then that’s your business, however you should not be misunderstanding it as standard operating procedure. Not everything is MCX-able. Try XMind, SPSS or Final Cut Pro.
Whatever business you work for may not care about testing Flash Player, but we run entire courses via video and other multimedia platforms. If Flash is broken or malfunctioning, entire lectures, tutorials and units are affected. It’s not just for playing games and getting web pages to function with all the bells and whistles. Regardless, you should never deploy anything without adequate testing, whether or not it’s critical to your business, because you will generate calls to your Service Desk.
Vendors change stuff. Expecting them never to is unrealistic. Even if Flash Player was in a standard Apple PKG, you shouldn’t be deploying it blindly either. Look at 11.3 and 11.4 and fpsaud. If you’re just blinding building and deploying through your workflow on an automatic basis, you have no idea what you’re actually distributing, and you have no idea what effect it will have on your environment.
I’m completely comfortable packaging Flash by hand. I don’t need any command-line trickery, and I don’t need MCX that may or may not work properly (and doesn’t apply to Flash Player anyway). I know what’s included in it and what’s not. I have standardised pre- and post-install scripts, and I simply throw the bits I need into it, adding in my customisations. Even if Flash Player came as a PKG, and as I do with every single version of every single product I deploy, I would still be assessing each product and each version on its own merits as to whether or not it’s better to deploy the vendor installer or my own. Rather than getting stuck in a single inflexible workflow.
Sorry, but I could never work your way. I don’t work in a rigid corporate environment. The education sector is fluid, and requires rolling with the punches as each random new concept or idea pops up – whether I think it’s a good idea or not (and often not) – rather than getting mad because something is slightly different than before and requires a new approach.
Okay, so wait, this is going into “clever dodge” territory. It is in fact, the Flash team’s responsibility to set up the installer so that with no work whatsoever, it will install with the most correct settings possible for the widest range of use cases.
This is not open to argument by anyone with a clue. It is their job, *their* job to ensure, in fact, that the default install of Flash is in fact *safe*. It may be not OPTIMAL for every environment, but it must be SAFE. There’s a difference there.
If there is a need for post install configuration, then that needs to be done by the best conventions for that platform, be that config files, GPO’s, or MCX settings. I don’t care that the Flash team needs to change stuff that’s true of every software vendor on the planet.
I do care that they don’t create installers that *lie* to me, and that is what the flash installer is currently doing. It is LYING to me about what has happened. If just running the package in the application by itself will not properly install Flash, then it is up to the Flash team to either:
1) Fix the installer so that an install with the package DOES work correctly.
2) Stop allowing the .pkg to be run on its own.
Either behavior is technically correct, only one is customer-friendly. The current behavior is neither. It’s lying to the user. That is not acceptable. Period.
This is not easy, but it is important. It was important enough to other parts of Adobe to spend a lot of time on installers, including the CS team, and the Acrobat team. If the Flash team wishes to piss people off by lying to them, that is of course their option, just as it is the AIR team’s option to make installing AIR as hard as possible in an automated fashion, thereby ensuring it’s only installed via specific request. Who loses there?
We’ll leave silly attacks at how the corporate environment is so rigid etc. alone, because they’re too incorrect to be worth the time to bother with, except to point out though that rather a lot of companies even unthinking drone commercial ones develop CONTENT based on Flash, and so are QUITE concerned with the current idiocy of the installer.
Oh, and the fact that there are applications like SPSS and FCP that aren’t manageable is not an indictment against management, it’s a sign that those dev teams are doing things the wrong way in terms of manageability.
“Sorry, but I could never work your way. I don’t work in a rigid corporate environment. The education sector is fluid, and requires rolling with the punches as each random new concept or idea pops up – whether I think it’s a good idea or not (and often not) – rather than getting mad because something is slightly different than before and requires a new approach.”
I think you assume to understand the environments the rest of us support. 🙂 Some of us have many clients around the world, mixed platform environments, our largest Mac population is 2,200+.
Trust me, none of our users are making widgets. We support many strictly regulated environments, multimedia, banking, health care, government, etc…and trust me, inability to quickly/effectively deploy Flash Player is a HUGE problem.
So while you’re right about “rolling with the punches” (we all do, it’s part of our job as admins). But your “rather than getting mad” statement is a little off base.
Adobe is exercising due diligence by openly discussing this very real issue openly. They know a lot of us are getting beat up over their mis-steps. But they’re right there, front and center, mostly because of the light that’s being shined on the Flash Player installer issue.
Don
(apologies for the grammar…tried to send out that last post and not miss a meeting. Don)
[…] TGB is back with more interesting comments. […]
Sorry TGB education is a cake walk compared to what some of deal with business. I deal with developers all over the world in multiple languages is no easy task. When I worked with educational institutions I could roll labs so easy across multiple buildings in no time. Student machines are a backup followed by the nuke and pave. Get over yourself.
Hidden within the Adobe Flash Player install package Adobe provides is a .pkg.
Mount the DMG.
Right click > Show Package Contents
Contents > Resources
There’s your “Adobe Flash Player.pkg” that will work with Munki.
Umm, thanks?
I think most of us are aware of that package (and even use it!) But it’s _not_ Adobe’s supported installation method, and there are minor issues when you use it. See the earlier posts in this series for the dirty details.
I’ve been disappointed in Adobe’s admin and enterprise support in general, and I don’t have a very demanding environment. All I distribute/deploy is Flash, Reader, and Acrobat; trying to find out how to do silent, trouble-free installs and updates has been close to impossible on Adobe’s labrythine website; googling the problem turned up a list of possibilities for various command switches that worked sometimes. It felt more like trawling for nuggets of folklore and magic spells than getting a clean solution from the true source — Adobe. It doesn’t help that at least 1 of the above 3 is updated by Adobe every couple of weeks or so, so then then the automatic Updater pops up letting all my users know they’re behind the times, and then they let me hear about it. It’s hard to believe that this problem hasn’t been raised and solved a decade ago.
So there are a few things in your comment. Reader and Acrobat are actually two of the easier things to push install. They come as standard packages, and with XI, Adobe released some things that make life easier for Mac Admins for once.
The manual for it is here: http://www.adobe.com/devnet-docs/acrobatetk/tools/MacWiz/CustomizationWizardforMac.pdf
the wizard is available at:
ftp://ftp.adobe.com/pub/adobe/acrobat/mac/11.x/11.0.00/misc/
and the IT documentation for Acrobat is here: http://www.adobe.com/products/acrobat/it-resources.html
The installers for updates for X and XI are package installers. The Acrobat team has, slowly, been doing a decent job of making things easier.
In your situation, flash is your real problem child, and that team…sigh.