How to create Flash Player Installer from their DMG, Best Practices

@Don, fair enough. My response was that the default settings in Casper Suite don't allow for using the FEU and FUT checkboxes in a policy/Casper Remote, etc to be used with a PKG, only with a DMG. I have done similar scripts myself for standalone package installs that needed to drop preferences to a user level Library folder. It works fine, but just checking a box in Casper Admin or a policy ain't gonna do it.

A few questions about the Adobe Flash auto-updater. I have been extracting the installer pkg as above and updating Flash with a policy. All works fine. In my situation I'd actually like to have the auto-updater function. The last version I installed is 11.3.300.268 and I don't see any users auto-updating. Do I need to customize the installation in order to implement auto-updating? Does the auto-updating work for a standard user? Thanks for any insights.

Yes. There's an item in the /Utilities folder that you need to capture for the update mechanism to work. (What it's called escapes me at the moment.)

Be aware though, that users still need admin rights to install updates through this mechanism. I think Adobe was rather stupid with that. Thus we're still pushing out the updates manually.

What are the benefits of creating a non-flat pkg over a snapshot dmg in Composer? This all seems like a lot of extra work and I don't see any positives.

@jarednichols: I'm right there with you. Once they remove the need for elevated privileges, we will start enabling that option as well.

To me there really isn't any huge advantages to using PKGs if it's not something already made for you that way. A PKG is useful if you're giving the package itself directly to a user to install something by hand because that's a known method to install for them, the DMG of files doesn't really work in that scenario.

In some instances using the capabilities within Composer can help streamline a few things. For example you can still package up Xcode app, but then include a postflight script to install the mobile support tools as well. Or when we install our root certificate, the file gets copied to the location we want and then the script runs the security command to install it. Let's say you want to blow away previous file version before install, to do that now in the JSS requires you to create a script of it anyway if you didn't have a DMG to uninstall. This is helpful in making packages idiot proof. Another person that may need to help with the system doesn't need to know the commands to install something like if they had to create a self service policy, all the little idiosyncrasy are baked into the PKG. Since you can't do anything like package dependencies in admin, it's helpful there, too. I try to keep things as modular as possible, but that can cause issues later if there is a dependency on another package.

In the managed system scenario a DMG can give you advantages when you index the package when you upload it. You can then uninstall those files easily (not that you can't do something similar with PKGs) and self-healing becomes an option.

@ernstcs wrote:

A PKG is useful if you're giving the package itself directly to a user to install something by hand because that's a known method to install for them, the DMG of files doesn't really work in that scenario.

Ditto...we only use PKG/MPKG, since all packages need to be usable by Help Desk, Desktop Support, Advanced Support, remote users, etc.

We use a loop script to FUT and FEU, and we don't miss the ability to uninstall (which can be problematic if an install overwrites or merges with existing files).

So while we use DMG as a delivery "envelope" for our packages, the format is still PKG/MPKG. The AAMEE fiasco is a good example where our delivery method fits in nicely with JAMF's workaround:

https://jamfnation.jamfsoftware.com/article.html?id=161

Don

So, according to Adobe's EULA, you're not allowed to dig the PKG out, you are supposed to use the following:

1. Mount the DMG
2. Execute the following command line: /Volumes/Flash Player/Install Adobe Flash Player.app/Contents/MacOS/Adobe Flash Player Install Manager -install

Unfortunately, this approved method does flash a dock icon. It also installs the Update Manager, and still respects the mms.cfg file.

More info here: http://managingosx.wordpress.com/2012/08/22/flash-mob/ (and the blog posts before and after that one.)

Sounds like something that can be scripted and pushed with Casper, but still requires a logged in user. They really need to give Jody Rodgers control there. ;)

For a while Adobe was asking enterprise folks to submit formal summaries of how risk/liability is impacted by our inability to easily deploy and patch Flash.

I think Adobe is listening. :)

Don

Along these lines, it appears that the latest Flash installer (11.5.502.149?) does not contain a PKG like it used to. Apparently the installer downloads the PKG behind the scenes when you run it (although this is failing on my system). Has anyone managed to locate a PKG of the latest Flash player?

UPDATE: Note to self, check the board before reviving an old thread. Thanks, @colonelpanic!

http://fpdownload.macromedia.com/get/flashplayer/pdc/11.5.502.149/install_flash_player_osx.dmg

Even if you use the version that downloads itself, if you let it download and unpack you can right-click on the dock icon and then Options>Show in Finder. Then you can perform the same steps you would take if you downloaded the DMG yourself.

I used Scott's method to grab the .pkg and it seems to be deploying just fine in my test group.

I guess i'm the only one doing a snapshot install package with the internal updates turned off. There's a lot of effort going on in this thread!

I used the Package Manifest method in Composer 8.63 and got a working install, though that obviously doesn't change the autoupdate settings. $0.02.