I deployed Flash Player via a Software Installation policy. How to upgrade?

Question

I have a Windows Server 2008 machine as my DC. Earlier this year I created a Software Installation GPO to deploy Adobe Flash Player plugin MSI. I assigned the policy to the computers, about half run Windows XP x86 and the other half Windows 7 x64. That all works like clockwork.

When I created the Software Installation Policy, I disabled the Flash Player plugin's automatic update feature by editing the MSI in Orca. I did this because I wanted all of my machines to run the exact same version of the plugin.

Now, some time has passed and a newer version of the Flash Player plugin has been released. It is time for me to push out the updated version of the plugin. I already have the new MSI, but I am lost on what to do next.

• I see the upgrades tab in the Software Installation GPO, but everything there reads like that would be used for add-ons to a larger master program and not for updates that are released over time.
• I have read that it is best to create a new Software Installation policy with the new MSI, revoke the old GPO, and assign the new GPO. I feel as though, over time, I will wind up with more revoked policies than active ones.
• I have also read that some people have had success by replacing the old MSI with the new MSI and simply telling the GPO to redeploy. This seems like a backdoor method that will only get me in to trouble.

In short, what is the correct, best-practice, or preferred way to roll out the new version via Group Policy?

Answer 1

I've done this many times with Flash Player (and other software). What you want to do is:

• Use ORCA to edit it with any customization that you want and save it as a transforms (or save it as a whole new MSI, whatever works for you).

• Put that new MSI (and transforms) on your software deployment share.

• Add this software (and transforms) to your existing policy. It will automatically detect it as an upgrade to your previous versions of Flash Player. You can add all versions in the same policy if that's how you've previously configured it (x86: plugin and ActiveX, x64: plugin and ActiveX) or you can continue with whatever GPO layout you already have. Just make sure that you're adding like-for-like in your policy and it will automatically detect these as upgrades.

• If, for whatever reason, they aren't automatically detected as upgrades, you can set this yourself in the policy. This is the correct way to handle this situation.

There's really nothing special to this.

One thing that you should think about is instead of editing the MSI with ORCA every time there's a new version, you can create an mms.cfg file as outlined here with Flash Player preferences. This file will not be touched across upgrades, so you only need to push out this file once and then you can deploy a vanilla Flash Player installation. I've used Group Policy File Preferences with Item Level Targeting to put this in the correct place on x86 and x64 machines in a mixed environment.

Answer 2

I believe the upgrade is the best-practise method for doing so. I have used this method quite extensively in the past without problems.

Add the new MSI as another Package in the Group Policy object, choosing the Advanced deployment method. It should be detected as an upgrade to the previously deployed Flash Player. If it's not you can add it to the updates tab manually.

Answer 3

I've had horrendous numbers of seemingly random failures (see my note at the conclusion of this answer) with some of the v9, v10, and v11 Adobe Flash MSI's not uninstalling or upgrading properly, leaving the MSI database on the PC in a state that makes me wary. I've ended up resorting to using a startup script that:

• Checks the HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayer\CurrentVersion registry value to see if the currently-installed version is current (adding a WOW6432NODE into that path, if necessary) and bailing if the version is current

• Uses the old, unsupported, and now next-to-impossible msizap.exe utility to remove known-failing MSIs from "back in the day" (including {2BD2FA21-B51D-4F01-94A7-AC16737B2163}, {B7B3E9B3-FB14-4927-894B-E9124509AF5A}, and {FA1D6742-0515-4A94-AD5D-F0484026E4A2}).

• Uses the Adobe-provided uninstaller EXE to silently remove any current versions of Flash

• Uses the current Adobe-provided EXE installer with the -install activex argument (I'm only installing the ActiveX control in most sites) to install the current version

• Writes out an 'mms.cfg. file to prevent automated upgrades

Here's a cleaned-up version of my startup script. You'd need to go out and grab the appropriate EXEs if you wanted to make this go.

@echo off
SET MSIZAP=\\my.domain.com\netlogon\bin\msizap.exe
SET DFSPATH=\\my.domain.com\dfsroot\Packages\Adobe

SET UNINSTALL=%DFSPATH%\uninstall_flash_player_x86.exe
SET INSTALL=%DFSPATH%\install_flash_player_11.4.402.278_active_x.exe 

rem Detect 64-bit Windows
IF NOT "%ProgramFiles(x86)%"=="" SET WOW6432NODE=WOW6432NODE\

SET VER_FLAG_KEY=HKEY_LOCAL_MACHINE\SOFTWARE\%WOW6432NODE%Macromedia\FlashPlayer
SET VER_FLAG_VALUE=11,4,402,278

REG QUERY "%VER_FLAG_KEY%" /v CurrentVersion | find /i "%VER_FLAG_VALUE%" > NUL 2>NUL
if errorlevel 1 goto do_install
goto :EOF

:do_install
rem Uninstall all old versions of Flash.
start /wait /min "" "%UNINSTALL%" -uninstall activex

rem MSIZAP all old versions
start /wait /min "" "%MSIZAP%" TW! {2BD2FA21-B51D-4F01-94A7-AC16737B2163}
start /wait /min "" "%MSIZAP%" TW! {B7B3E9B3-FB14-4927-894B-E9124509AF5A}
start /wait /min "" "%MSIZAP%" TW! {FA1D6742-0515-4A94-AD5D-F0484026E4A2}

rem Run new installer
start /wait /min "" "%INSTALL%" -install activex

rem Block future automatic updates
SET DEST="%windir%\system32\Macromed\Flash\mms.cfg"

rem Detect 64-bit Windows
IF NOT "%ProgramFiles(x86)%"=="" SET DEST="%windir%\SysWOW64\Macromed\Flash\mms.cfg"

rem I'm using "sort" here because the redirect is being interpreted as "1>" and
rem doing "1 >" causes a space to be stored in the file, which "breaks" the file.
echo AutoUpdateDisable=1|sort>%DEST%

The problems I've seen uninstalling old Flash MSIs have mostly been:

• "Adobe Flash Player 11 ActiveX -- Error 1714.The older version of Adobe Flash Player 11 ActiveX cannot be removed. Contact your technical support group. System Error 1612."

• "Error 2753: The file 'installax.exe' is not marked for installation"

The straw that broke the camel's back, for me, was seeing these errors happening randomly in a Customer site with 1,000+ client PCs. I need to be sure that Flash updates are happening and having MSIs randomly fail to uninstall isn't an option. The fact that the MSI failures happen on each subsequent boot, slowing the boot process down, just adds insult to injury.

I haven't looked at a v11 MSI in detail. The v9 and v10 MSIs are nothing more than a custom action to execute the EXE-based Flash installer with command-line arguments. I wasn't impressed in the quality of the MSIs, because using Windows Installer to just run your EXE-based setup isn't using Windows Installer.

Answer 4

If you add a newer version of flash.msi to the same GPO, Windows will detect that this is an update to the previous one (the older one is listed in the 'updates' tab). It will also know that it can install the new one over the old one, without removing the old one first (checkbox in the update tab is checked).

This magic is made possible by the GUIDs in the msi-file, that are put in by Adobe.

You can add any number of new flash.msi to the same GPO, but you can also eventually remove old ones.

One exception was version 11.4.402.278, because in this case Adobe had put in the wrong version number in some places, so it failed to correctly update itself.

For this reason I highly recommend to always have a separate GPO that applies only to a test machine, and try there for each new version: upgrade, downgrade, upgrade.

Please note that this magic does not work with all msi files. Then you must add the old ones manually to the list in the updates tab, and then you should leave the checkbox unchecked.