This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Flash Player ActiveX 11.8 does not install

FormerMember
FormerMember

We use CM2012 with PM and we are facing an issue installing Flash Player ActiveX 11.8. AF 11.8 is not getting installed (MSI or EXE) on any of the Win7 (64 bit) company laptops. We have been working with Solarwinds technical support but unfortunately the issue has not been resolved.

We have tried everything we have been able to and we are not making any progress. In checking with Microsoft Tech support they have validated the process and they are in agreement with us that CM/SCUP is working as expected and that perhaps something within the package installation process does not work.

Any other package seems to work (Java, Firefox, etc.) including Flash 11.8 Plugin. We are tried removing Flash from the test machines using the Adobe Cleanup tool but we are having the same issue. We have also tried different images and  still the same problem.

The following post at TechNet is something similar to what we are having Flash Plugin but Flash Active X does not get installed from the CM Software Center we receive the following error message: The software change returned error code 0x80070643(-2147023293).

http://social.technet.microsoft.com/Forums/systemcenter/en-US/c2912ee5-9b96-4c94-9440-c8d9c8dfbb72/flash-11x-msi-wont-install

We are reaching to the community seeking for help to hopefully get this resolve as soon as possible.

Thank you.

  • Greetings Luis.

    Firstly, since the issue is about INSTALLATION of the Adobe Flash ActiveX product, the truth is that neither WSUS, nor Configuration Manager, nor Patch Manager, are products involved in this problem. I believe that Microsoft Technical Support has told you as much already. Your ticket with SolarWinds support is being discussed internally, and I've provided the same feedback just a short time ago.

    Fundamentally this is an issue between the Adobe Flash v11.8 ActiveX installer and the Windows 7 SP1 x64 systems affected, and your most appropriate avenue for investigation and resolution of this issue is with Adobe. As I understand the scenario, the installer has been properly delivered to the client, but the installation fails. As such, neither WSUS, Configuration Manager, nor Patch Manager are subjects of this issue, as all of those components properly performed their purpose (i.e. deliver the installer to the client and launch the installer). Once the installer launches, the issue is entirely between the Adobe Flash ActiveX v11.8 installer and the operating system. It's entirely possible that there are not-yet-identified issues with the Flash ActiveX v11.8 x64 installer and Win7 x64 systems. (As a contribution, I will make a point to deploy the v11.8 x64 ActiveX package to my own systems and watch for any unusual results.)

    As for the post at Technet... that post was from 18 months ago about an Adobe Flash v11.1 32-bit installer in November 2011, so I would suggest that discussion likely has very little to do with your current scenario a year and a half later involving Flash v11.8. Since that time, Adobe no longer publishes 32-bit-only/64-bit-only installers. The installers were made architecturally-agnostic with the release of Flash v11.3. Furthermore, the "fix" documented in that threat was entirely superficial. Changing the "Can request reboot" to "Always requires reboot" does absolutely nothing on the client-side equation of the behavior, because that package attribute is an informational only attribute. I'm not able to determine what did or did not resolve that issue with the v11.1 x86 installer, but I do know that the WUAgent does not engage in any behavior based on the attribute that was changed. Whether the WUAgent tags an update as 'reboot required' or not is entirely driven by the result codes returned by the product installer. My inclination is that the reported 'fix' was entirely coincidental and something else is attributable to the resolution of that issue -- something we will likely never be able to determine.

    My best suggestion to you in this scenario is to open a support ticket with Adobe and press them to investigate and identify why the Flash ActiveX v11.8 installer is failing on your Windows 7 x64 systems. My inclination is that it might have something to do with the state of the Internet Explorer x64 product, although that's purely speculation on my part.

    Another point to be made is with regard to whether the IE x64 browser is actually being used. Fact is, if IE x64 is not being used, then the Flash ActiveX x64 product probably isn't even needed, and the simple solution may be to not install the Flash ActiveX x64 package at all; however, the x86 package may still be required, and that's the second part of this diagnostic effort -- is it the x86 installation that's failing, or the x64 installation?

    To determine that, enabling MSI Logging and launching the Flash ActiveX installer interactively may provide some logging detail not currently available via the standard WUAgent functionality.

    And finally, there's always a possibility that the behavior is directly related to the installation file itself. Was this an Adobe Flash v11.8 package/installer obtained via the Adobe catalog (and downloaded directly from Adobe), or was this an Adobe Flash v11.8 package/installer obtained from the SolarWinds catalog and downloaded via an email link pursuant to an Adobe Redistribution Licensing Agreement? You mention "CM/SCUP" in your post, but SCUP is not part of the CM/PatchManager environment, so I'm quite curious as to how/when SCUP became part of this scenario.

  • I suggest having a look at the Flash player install log. On a 64-bit machine, this will be in "C:\Windows\SysWOW64\Macromed\Flash\FlashInstall.log" for the 32 bit installer and "C:\Windows\System32\Macromed\Flash\FlashInstall.log" for the 64 bit installer. If you are using the MSI installer, you could also add a switch "/l* <log file path>" to create an msi log file at the specified path.