Software Deployment

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

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

verbose log??

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

ORIGINAL: jmcfadyen
note: "local system" will not have access to this path in default configurations This seems to me to be the more likely cause. Simply put, the System account has no network access at all, period. If the install works using the local admin account, then that implicates your deployment system's running of the batch file in Local System context as the culprit.

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! ;)

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

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...

active_x.msi

Adam,

Not sure if it helps, but I have Adobe Flash 9.0.124.0 on my machine.
I created an install.bat with the following commands and it works just fine:

Rem Install Adobe Flash 10 ActiveX
msiexec /i "install_flash_player_10_active_x.msi" TRANSFORMS="install_flash_player_10_active_x.mst" /qb

Rem Install Adobe Flash 10 Plug-In
msiexec /i "install_flash_player_10_plugin.msi" /qb

I checked my windows\system32\macromed\flash and found the ocs for version 10.0

I also checked via: http://www.macromedia.com/software/flash/about/
and it shows the latest version is installed.

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.

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".

ORIGINAL: adamj777
Thanks for the info, VBScab! I changed the switch as you suggested and the output is identical to what I posted above. D'oh! I couldn't have been thinking straight. Of course that wouldn't work for the nested MSIs because the engine doesn't pass through the switches used for the parent. Find the command line in the call to the children and change it there.

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!

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