detection methodology problems with 15.0.0.189 MSI installers

[AJM-B]

I have made the latest 16.x updates available to my environment via SCUP + Config Mgr 2012 R2, and I'm noticing that clients with Adobe Flash 15.0.0.189 MSI (ax & plugin) deployed to them are trying to install even though software updates have now brought the version of Adobe Flash (ax & plugin) installed on these pc's to the 16.x version. Please fix detection methodology on published MSI's to prevent this kind of thing in the future. Nothing appears to be getting screwed up, but users are sending tickets our way about "failed adobe updates".

[jeromiec83223024]

Thanks for the feedback.  I've filed the following bug on your behalf, and opened it to the installer team.

Bug#3909869 - MSI Installation - Flash Player 16 clients trying to install Flash Player 15 updates

[AJM-B]

Important additional details: I think, specifically, the problem is that Config Mgr detection methods are looking for a particular msi guid, and adobe scup catalog updates must have changed the guid that was present. I'll try to confirm that theory tomorrow if I have some time.

update: this is what app event log reported when the MSI tried to run after 16.x scup updates had successfully applied (no errors during those actions on previous day).

Adobe Flash Player 15 ActiveX -- Error 1704.An installation for Adobe Flash Player 15 Plugin is currently suspended.  You must undo the changes made by that installation to continue.  Do you want to undo those changes?

Now...as far as I can tell there should have been no reason for a suspended plugin installation hanging around - as no errors were reported during the scup update for flash player plugin 16.x.

[Guest]

Dear AJM-B

I reported the same bug in a different thread:

https://forums.adobe.com/thread/1551106

I suspect that the problem is not with the previous Flash Player versions deployed by MSI, but for the installations made manually though the web.

Unfortunately it doesn't look like somebody is working on it...

I wonder how the installer is detecting the existence of the previous software. Maybe a workaround would be to replace the GUID in the registry with a script before launching the installer...

[jeromiec83223024]

It's assigned to and engineer and a fix is in progress.  It's currently targeted to Flash Player 17. 

[Guest]

Thanks for the update, Jeromie.

[AJM-B]

Is any kind of workaround available? I'm discovering I have a significant number of workstations affected by this issue - and it is preventing any further MSI distribution of software required at various locations. It's a big deal.

[Guest]

I haven't found any, because even if I previously uninstall the old version and then install the new one with a script, very often the new one seems to be properly installed, but it is not working, so you have to manually uninstall it and install it again...

[_maria_]

Hi AJM-B and Barahona,

As Jeromie mentioned, we are working on this issue (although the bug he refer's to is slightly different issue) and hope to have a workaround published today or tomorrow.  I'll update this thread and "The version of the Player that you are trying to install is lower than what is currently installed"... when the information is published.

Barahona,

What do you mean by "very often the new one seems to be properly installed, but it is not working,"?  Is it registered? After you install the new one, what displays in the Control Panel listing of programs?

--

Maria

[AJM-B]

I have some additional details for you guys; this is what I've been using with some success as a workaround, maybe it will give you some insight as to what exactly is going wrong:

1. check for hklm\software\microsoft\windows\currentversion\installer\inprogress & ...\syswow64\... (same path under syswow64 on 64-bit Windows)
2. for each one that exists, check creationtime on the .ipi file given; if it's > 1 day old, this is probably a 'stuck in progress' installation = delete the .ipi file and the related registry items we just checked; it's important to check the time so we don't interrupt a legitimate install-in-progress.
3. stop all msiexec processes - they'll start back when something needs em

Now...seeing as this works, I'd say there's a pretty good chance that the MSI's (ax and plugin) aren't properly cleaning up the registry, filesystem, and releasing the msi global mutex when they are done. That being said, on the systems I've tested this fix on, other non-flash installs / uninstalls are proceeding normally (yay) - but if you try to install/uninstall the affected flash programs, you'll still receive a UI popup about the "version of flash you are trying to install is older" that I think is preventing silent, automated uninstallation because the process waits on a response to the UI dialog, which will appear in session 0 if the process is running as SYSTEM (it will if you're using Configuration Manager 2012).

[_maria_]

Hello,

We are aware of this issue and are working on a solution.  In the mean time we have identified several workaround options.  The workaround options are outlined in the bug https://bugbase.adobe.com/index.cfm?event=bug&id=3928747.  Unfortunately, the bug description is limited in characters, so you'll need to download the file attached to the bug record to get full details and all of the workaround options.

We have identified that bug Bug#3909869 - MSI Installation - Flash Player 16 clients trying to install Flash Player 15 updates  s not related to this issue.  For comments on this issue please comment on bug https://bugbase.adobe.com/index.cfm?event=bug&id=3928747 instead of the other bug record.

Thank you in advance, and we apologize for the delay in resolving this issue.

--

Maria

[Guest]

m_vargas wrote:

Barahona,

What do you mean by "very often the new one seems to be properly installed, but it is not working,"?  Is it registered? After you install the new one, what displays in the Control Panel listing of programs?

--

Maria

Dear Maria,

Yes, it's exactly like that, program appears in the Control Panel with the newest version, but it doesn't work at all...