Adobe Flash Player 14.0.0.176 released

[#1]

Security bulletin: http://helpx.adobe.com/security/products/flash-player/apsb14-18.html

Direct download (assuming you have already accepted their distribution agreement): http://www.adobe.com/products/flashplayer/distribution3.html

I just revised my smart group to .176 and flushed the log for @rtrouton Flash script:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_adobe_flash_player

[jhalvorson]

Is it better practice to A) revise the smart group and flush the logs or B) Clone the smart group and revise that for use with a new cloned policy of the prior version?

To date, when an updated version of Flash is released I:
1st) disable the existing policy, for example version 14.0.0.145
2nd) clone the .145 smart group and revise it to those that need.176 3rd) clone the 145 policy to become a .176 update existing policy.
4th) A day or two later, delete the .145 smart group and .145 deploy policy.

Long term, I am not sure there is much of a difference other than I am creating new smart groups and polices for each and every update. In either case, you lose the history of updating the flash player for a computer.

Are there advantages to revising the existing smart group and policy?

[alexjdale]

One good thing about the Flash installer is that it will refuse to install if a newer version is already installed. There's a pretty sizable margin for error when applying Flash updates.

[mm2270]

Yeah, unlike Adobe Reader updates, which will happily downgrade a client to the previous version if you're not careful to future proof your Smart Groups. (ask me how I know this :p )

Our process right now is to temporarily disable the policy, update the Smart Group and policy information with the new package and then re-enable it. Hopefully if our SG logic is correct, the Macs not running that version should fall into the group and start getting the push.

Going forward, I've been working on ways to sidestep the entire Smart Group creation and the pkg upload process, and go directly to doing script based version checking and comparison and download and install the new version right to the client. I've gotten a bit tired of needing to future proof Smart Groups to prevent machines falling into a group they don't belong to.
If our users were not admins, it would potentially be easier since they couldn't install their own updates, but since they are, it becomes a big unknown when users will install the latest version of something and end up in a group they should not be in because of the known 'versions as strings' issue.

[artrip_18]

@jhalvorson

I lean toward option A.

When Flash player and other plugins are updated I do the following:

1. disable the policy
2. clear the logs of the policy
3. change the smart group to reflect the new version number
4. add the updated package to the policy and re-enable it