I am having a rather difficult time creating a rather simple install script for the latest Flash MIS files. It seems that I can run each of the files manually and click my way through the install without any trouble. If I attempt to run the MSI files via a batch file, both MSIs throw Windows Installer Error 1619:

"This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package."

Here is my script (names have been changed to protect the innocent):

@echo off
SETLOCAL
SET DEPOTDIR=\\server\share\Adobe\Flash Player 10.0.12.36

:inst1001236
echo Installing Adobe Flash player v10.0.12.36 (Active X)...
"%WINDIR%\System32\msiexec.exe" /I "%DEPOTDIR%\install_flash_player_active_x.msi" REBOOT=REALLYSUPPRESS ALLUSERS=1 ADDLOCAL=ALL /qb!-

echo Installing Adobe Flash player v10.0.12.36 (Firefox)...
"%WINDIR%\System32\msiexec.exe" /I "%DEPOTDIR%\install_flash_player_plugin.msi" REBOOT=REALLYSUPPRESS ALLUSERS=1 ADDLOCAL=ALL /qb!-

echo Disabling Auto Updates...
if not exist "%windir%\system32\Macromed\" md "%windir%\system32\Macromed\"
if not exist "%windir%\system32\Macromed\Flash\" md "%windir%\system32\Macromed\Flash\"
copy /Y "%DEPOTDIR%\mms.cfg" "%windir%\system32\Macromed\Flash\"

:endscript
ENDLOCAL


I have tried moving everything to a local directory so that the installers are not being run via a UNC share but I get the same results.  I also tried stripping all of the Properties from the command line with no success. Does anyone have any suggestions on how to script these installers? What am I missing?

Thanks in advance!
-Adam

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
0

error 1619 - This installation package could not be opened. Verify that the package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer package.

there might be issue with
SET DEPOTDIR=\\server\share\Adobe\Flash Player 10.0.12.36

Spaces in the directory. try removing the spaces or replacing them with a "_" or "-" and see if it works

Answered 11/07/2008 by: bheers
Second Degree Blue Belt

Please log in to comment
0

Thanks for your input, bheers...

I also tried the script without the variable entirely. However, I had the same results.

As far as quotes go, I use this format on all my msi installers and am certain it works. I had to try a few things out at the beginning... It turns out that the environment variable should be set without quotes, while the command line that calls the variable needs them. This allows the full command line to be interpreted correctly when using an environment variable.

I am beginning to suspect it might be some sort of security issue. Perhaps the msi is not a MS-signed msi and so Windows Installer treats it differently?? Not sure if this can happen or not but with all these security patches being applied lately, I wouldn't put it past MS to employ more aggressive checking of such things... This IS the first time I have encountered this situation... Anyone have any info which might lend credence to this hypothesis?  :)

**edit I also tried putting the files in a directory structure with no spaces. No luck.

-Adam

Answered 11/07/2008 by: adamj777
Senior Yellow Belt

Please log in to comment
0

verbose log??

Answered 11/07/2008 by: kiptek
Second Degree Green Belt

Please log in to comment
0

check perms on the UNC paths. try to connect to that share using the deployment account.

note: "local system" will not have access to this path in default configurations

Answered 11/09/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
ORIGINAL:  jmcfadyen
note: "local system" will not have access to this path in default configurations
Answered 11/10/2008 by: VBScab
Red Belt

Please log in to comment
0

Thanks for your continued input, folks...

All very good suggestions. However, I have ultra-simplified my testing to the following script being run from the C:\Flashinst directory under a domain account with local admin rights.


@echo off

:inst901150
echo Installing Adobe Flash player v10.0.12.36 (Active X)...
msiexec.exe /I install_flash_player_active_x.msi REBOOT=REALLYSUPPRESS ALLUSERS=1 ADDLOCAL=ALL

echo Installing Adobe Flash player v10.0.12.36 (Firefox)...
msiexec.exe /I install_flash_player_plugin.msi REBOOT=REALLYSUPPRESS ALLUSERS=1 ADDLOCAL=ALL

echo Disabling Auto Updates...
if not exist "%windir%\system32\Macromed\" md "%windir%\system32\Macromed\"
if not exist "%windir%\system32\Macromed\Flash\" md "%windir%\system32\Macromed\Flash\"
copy /Y mms.cfg "%windir%\system32\Macromed\Flash\"

:endscript
pause

When I run the batch file, each msi produces the Error 1619 dialog. When I double-click on each MSI installer, it runs fine. I does not seem to have to do with account security, filesystem permissions, paths with spaces, or network access. Something very strange about these MSIs. I will have to open a support call with Adobe, it seems. Imagine: an Enterprise installer that cannot be run from a script! Now, THAT's what I call secure!  ;)

If anyone has any more ideas, I would sure welcome them!  :)

FYI: Here are the contents of the verbose logs (/lvx):

=== Verbose logging started: 11/12/2008  11:17:41  Build type: SHIP UNICODE 3.01.4000.4039  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (38:94) [11:17:41:677]: Resetting cached policy values
MSI (c) (38:94) [11:17:41:677]: Machine policy value 'Debug' is 0
MSI (c) (38:94) [11:17:41:677]: ******* RunEngine:
            ******* Product: install_flash_player_active_x.msi
            ******* Action:
            ******* CommandLine: **********
MSI (c) (38:94) [11:17:41:693]: Note: 1: 2203 2: install_flash_player_active_x.msi 3: -2147287038
MSI (c) (38:94) [11:17:41:724]: MainEngineThread is returning 2
=== Verbose logging stopped: 11/12/2008  11:17:41 ===


=== Verbose logging started: 11/12/2008  11:17:43  Build type: SHIP UNICODE 3.01.4000.4039  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (B4:94) [11:17:43:921]: Resetting cached policy values
MSI (c) (B4:94) [11:17:43:921]: Machine policy value 'Debug' is 0
MSI (c) (B4:94) [11:17:43:921]: ******* RunEngine:
            ******* Product: install_flash_player_plugin.msi
            ******* Action:
            ******* CommandLine: **********
MSI (c) (B4:94) [11:17:43:936]: Note: 1: 2203 2: install_flash_player_plugin.msi 3: -2147287038
MSI (c) (B4:94) [11:17:43:952]: MainEngineThread is returning 2
=== Verbose logging stopped: 11/12/2008  11:17:44 ===


Yep, that's it!  ;)

Answered 11/12/2008 by: adamj777
Senior Yellow Belt

Please log in to comment
0

'/LVX' only gives you 'extra debugging information'. Use '/L*V' - THAT'S verbose! :)

Answered 11/13/2008 by: VBScab
Red Belt

Please log in to comment
0

Thanks for the info, VBScab! I changed the switch as you suggested and the output is identical to what I posted above. These installers just do not work on any machine when invoked from a script! I am stumped...

Answered 11/13/2008 by: adamj777
Senior Yellow Belt

Please log in to comment
0
Answered 11/13/2008 by: aek
Purple Belt

Please log in to comment
0

Thanks, aek...

Yeah, it is quite strange... I have simplified my batch files to exactly what you have in yours (except for TRANSFORMS) and I get error 1619 dialog when I try to run from the batch file. I am using the MSIs obtained from the free Enterprise License download site. Double-clicking on the files, allows the to run fine.

I just re-downloaded the MSIs from Adobe and the problem persists. We have been pushing flash in this manner for the past seevral versions. In fact, we re-use the same batch file. I've not seen anything like this before.

Answered 11/13/2008 by: adamj777
Senior Yellow Belt

Please log in to comment
0

I was having EXACTLY the same problem today until I realized that, in this version, they added the version number, _10_, to the MSI file name: "install_flash_player_10_active_x.msi".

Answered 11/13/2008 by: propayne
Yellow Belt

Please log in to comment
0
ORIGINAL:  adamj777
Thanks for the info, VBScab! I changed the switch as you suggested and the output is identical to what I posted above.
Answered 11/14/2008 by: VBScab
Red Belt

Please log in to comment
0

OMG, how embarrasing! [:o]

Yes, you are right. They snuck a version number into their msi filenames! And, you know, I used to gripe about the fact that their msi filenames did not include a version number... Talk about turning the tables on me! What was once routine, suddenly did not work and I was too cross-eyed to notice!  ;) I guess I just panicked...  Sorry for wasting the board's time!!!

Thanks, propayne!

Answered 11/14/2008 by: adamj777
Senior Yellow Belt

Please log in to comment
0

It wasn't a total waste of time...  I couldn't figure it out for myself until after I found this post.

Answered 11/14/2008 by: propayne
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity

Share