Today I was creating a new application in order to deploy the latest Adobe Flash Player 11.7.700.202 that recently got released. I proceeded with my normal workflow and when the application was ready to be test deployed, I was experincing about 50% failures across the lab environment clients. Normally it’s really easy to create an application for Adobe Flash Player and deploy it. Previously it had worked fine to just let the installer take care of uninstalling the previous version. For some reason, this didn’t work with the latest version released by Adobe. I started out with looking at the AppEnforce.log on one of the clients that reported the enforcement as failed.

In the AppEnforce.log file, I could determine that it failed with exit code 1603.  I looked up the exit code here, and found out that there were an Fatal error during installation. Fatal sure, but that’s not really enough to go on.

35_6

In order to get a deeper understanding of the issue, I browsed into the C:\Windows\CCMCache folder on the client and ran the following command:

msiexec.exe /i flash_player_11.7.700.202_plugin.msi /qn /l* C:\temp\flash.txt

Almost at the top of the file, I started seeing errors. The one that I was interrested in is shown in the below picture:

35_5

So it’s not able to uninstall the previously installed version. Since I’m a huge fan of PowerShell, I ran the following command to see what versions was installed:

Get-WmiObject -Namespace "root\cimv2" -Class Win32_Product -ComputerName computer_name | Where-Object {$_.Name -like "Adobe Flash*"}

The out put from this command was didn’t give me the information I needed, though it looked like there were some corrupt installations. It also showed me that 11.7.700.202 looked to be installed, but it was not available in Add/Remove programs.

35_7

Running the following command was able to give me more information:

Get-WmiObject -Namespace "root\cimv2" -Class Win32_Product -ComputerName computer_name | Where-Object {$_.Name -like "Adobe Flash*"} | Select PackageName

Since I always give the MSI installers a proper name and versioning, this showed me that the previously installed version was 11.6.602.180.

When I ran the MSI installation file for 11.7.700.202 by just double clicking on it, I got this popup (the picture show the installation of the ActiveX version, since that deployment the same problem as for the Plugin version):

35_2

I assumed that the folder it referred to had already been removed by the ConfigMgr client, and I was right. When clicking Cancel, an error message appeared :

35_3

Looking through the Registry and searching for the above folder C:\Windows\ccmcache\4w, I found a set of keys where the 11.6.602.180 installer had stored the folder in e.g. the LastUsedSource value. The full path was HKLM\SOFTWARE\Classes\Installer\Products\0E7316430617B304DA12F30FD15230B7\SourceList.

35_1

I exported the 0E7316430617B304DA12F30FD15230B7 key and then deleted it. When running the installer again by only double clicking on it, the installation succeded. So I decided to create a VBscript that would delete the registry key and all it sub keys and value, after that I’d verified that the key was the same on all other lab environment machines. The script looks like this:

On Error Resume Next
Const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Classes\Installer\Products\0E7316430617B304DA12F30FD15230B7"

DeleteSubkeys HKEY_LOCAL_MACHINE, strKeypath 

Sub DeleteSubkeys(HKEY_LOCAL_MACHINE, strKeyPath) 
    objRegistry.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubkeys 

    If IsArray(arrSubkeys) Then 
        For Each strSubkey In arrSubkeys 
            DeleteSubkeys HKEY_LOCAL_MACHINE, strKeyPath & "\" & strSubkey 
        Next 
    End If 

    objRegistry.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath 
End Sub

strPath = """msiexec""" & " /i" & " flash_player_11.7.700.202_plugin.msi" & " /qn"
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run strPath, 1, True
Set WshShell = Nothing

I then updated the application in ConfigMgr to run this script as the installer program and deployed it. The AppEnforce.log file now showed me an exit code of 0 on all clients.

35_4

I really don’t like that MSI installers store their LastUsedSource value in the registry, atleast not when deploying applications with ConfigMgr. All clients in the lab environment eventually got the latest Adobe Flash Player 11.7.700.202 by using the above script as a wrapper.

Nickolaj Andersen
Principal Consultant and Enterprise Mobility MVP. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows deployments and Automation. In 2015 Nickolaj was awarded as PowerShell Hero by the community for his script and tools contributions. Author of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService and a frequent speaker at user groups.

(20)

comments
  • Daniel
    Posted at 17:13 May 23, 2013
    Daniel
    Reply
    Author

    Simply out of curiosity and nothing else…

    Why wouldn’t you use SCUP for this update?

    • Nickolaj
      Posted at 18:57 May 23, 2013
      Nickolaj
      Reply
      Author

      I’ve experienced to many unsuccessfull installations on clients when using SCUP. Mainly because e.g. Firefox when running, would cause the Adobe Flash Plugin to fail to install when pushed through SCUP. I found it easier to deploy through ConfigMgr up until now.

      Regards,
      Nickolaj

  • ben
    Posted at 14:12 May 24, 2013
    ben
    Reply
    Author

    So this problem could have been avoided if you were utilising Configuration Manager’s Windows Installer Source Path features?

    perhaps this time you will import the product code for the msi into the Application Deployment?

    • Nickolaj
      Posted at 14:36 May 24, 2013
      Nickolaj
      Reply
      Author

      I always import the product code. But in this case there where no URL key in the registry with the value for the DP.

      Regards,
      Nickolaj

  • Chinni
    Posted at 11:40 August 10, 2015
    Chinni
    Reply
    Author

    Delete flashplayer key from HKLM\SOFTWARE\Macromedia and HKLM\SOFTWARE\Wow6432Node\Macromedia (or) rename flashplayer as old key. Now Adobe flashplayer will be installed successfully. Tested and it worked.

  • fred
    Posted at 15:28 February 12, 2016
    fred
    Reply
    Author

    I will immediately seize your rss feed as I can’t to find your email subscription link
    or newsletter service. Do you’ve any? Kindly allow me recognize so that
    I may subscribe. Thanks.

  • Jesper
    Posted at 10:26 February 19, 2016
    Jesper
    Reply
    Author

    this is so awesome,
    the tip about “HKLM\SOFTWARE\Classes\Installer\Products\” helped resolve my problem

    thank you very much 😀

  • Blaf
    Posted at 00:41 November 5, 2016
    Blaf
    Reply
    Author

    Hello,
    I’ve tried to use same script and configure deployment.
    Would you mind just to provide more details related to this post:
    I then updated the application in ConfigMgr to run this script as the installer program and deployed it.
    I have included vbs script as detection method, or should I run script as installer.
    Additionally I have only edited script to include current version of FlashPlayer, changed only this part: flash_player_11.7.700.202_plugin.msi
    with this
    install_flash_player_23_active_x.msi
    Sorry, I am not most familiar with Visual Basic, but this article points right into the problem which I am experiencing.
    Thank you.
    Please advise right steps.
    I am experiencing same problem, 50% FlashPlayer installations failing.

  • fpSew
    Posted at 05:01 March 20, 2017
    fpSew
    Reply
    Author

    qquickm celexa buy celexa
    buy prozac online
    xbreathe paxil

  • Leave a Reply