none
Package install keeps failing with exit code 1619

    Question

  • Hello,

    I am hoping some one couild help me out with this. I am trying to deploy a simple .exe package from SCCM 2007 to two test computers. I adverstied the package to a collection with two test pcs and when I went to view the Status of a specific advertisement it showed that the install failed. I attached screen shots from the execmgr.log and also a screen of the switces I used when I created the program.

    Also, I was able to install the program with no problem frrom the command line using ADS1996.EXE /S /v/qn

    but when I use the same command in sccm it fails

    From my understanding error 1619 means "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."


    Phil Balderos

    Tuesday, September 17, 2013 6:53 PM

Answers

  • Error code 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."

    This indicates that the exe you were given by the vendor is simply a wrapper for an MSI -- a wrapper that's doing a poor job of extracting its files.

    You can use procmon to see what's going on and they may help.

    First I would try is manually extracting the files myself and capturing them from the temp directory when the exe runs just to see what's all in there and potentially directly using the MSI instead of their crappy wrapper. It really depends on what you find in it though.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Phil Balderos Thursday, September 19, 2013 11:27 AM
    Tuesday, September 17, 2013 8:54 PM
    Moderator
  • OK

    As sccm installs the application as system, you try to see if that is the problem.

    Here is a guide how to run things as local system with psexec, like the sccm client do:

    http://richardbalsley.com/a-simple-tip-to-test-software-installation-using-the-local-system-account

    • Marked as answer by Phil Balderos Thursday, March 24, 2016 3:12 PM
    Tuesday, September 17, 2013 7:49 PM
  • That looks really strange, more like your extractor opened an MSI.

    What happens if you manually run the setup? Can you grab the extracted files from %temp%?


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Phil Balderos Thursday, March 24, 2016 3:12 PM
    Tuesday, September 17, 2013 9:51 PM
    Moderator

All replies

  • Hi Do you run the package from a dp or do you download it to the client and run from the cache?
    Tuesday, September 17, 2013 7:14 PM
  • Hi Do you run the package from a dp or do you download it to the client and run from the cache?

    Hello Henrik,

    Thanks for the quick response. I have the option set to "Download content from distribution point and run locally"

    Its very strange becasue I can install the package .exe from the command line on the pc only

    Phil


    Phil Balderos

    Tuesday, September 17, 2013 7:28 PM
  • OK

    As sccm installs the application as system, you try to see if that is the problem.

    Here is a guide how to run things as local system with psexec, like the sccm client do:

    http://richardbalsley.com/a-simple-tip-to-test-software-installation-using-the-local-system-account

    • Marked as answer by Phil Balderos Thursday, March 24, 2016 3:12 PM
    Tuesday, September 17, 2013 7:49 PM
  • OK

    As sccm installs the application as system, you try to see if that is the problem.

    Here is a guide how to run things as local system with psexec, like the sccm client do:

    http://richardbalsley.com/a-simple-tip-to-test-software-installation-using-the-local-system-account


    Thanks I have installed software on this computer before using sccm with no problem. If it does require an admin account to install what would you suggest?

    Phil Balderos

    Tuesday, September 17, 2013 8:45 PM
  • Error code 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."

    This indicates that the exe you were given by the vendor is simply a wrapper for an MSI -- a wrapper that's doing a poor job of extracting its files.

    You can use procmon to see what's going on and they may help.

    First I would try is manually extracting the files myself and capturing them from the temp directory when the exe runs just to see what's all in there and potentially directly using the MSI instead of their crappy wrapper. It really depends on what you find in it though.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Phil Balderos Thursday, September 19, 2013 11:27 AM
    Tuesday, September 17, 2013 8:54 PM
    Moderator
  • Error code 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."

    This indicates that the exe you were given by the vendor is simply a wrapper for an MSI -- a wrapper that's doing a poor job of extracting its files.

    You can use procmon to see what's going on and they may help.

    First I would try is manually extracting the files myself and capturing them from the temp directory when the exe runs just to see what's all in there and potentially directly using the MSI instead of their crappy wrapper. It really depends on what you find in it though.


    Jason | http://blog.configmgrftw.com

    Thanks Jason,

    This is what I comes out when I extracted it? I have extracted other .exe in the past and was able to find the .msi but not in this case. This install is crappy.


    Phil Balderos

    Tuesday, September 17, 2013 9:28 PM
  • That looks really strange, more like your extractor opened an MSI.

    What happens if you manually run the setup? Can you grab the extracted files from %temp%?


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Phil Balderos Thursday, March 24, 2016 3:12 PM
    Tuesday, September 17, 2013 9:51 PM
    Moderator
  • That looks really strange, more like your extractor opened an MSI.

    What happens if you manually run the setup? Can you grab the extracted files from %temp%?


    Jason | http://blog.configmgrftw.com


    I don't know could it be an MSI? I used the .exe command line switches. I assumed it was an .exe because it ended in .exe. I even ran the .exe /? And was presented with a list of .exe switches. I am going to manually run the setup and try what you Suggested. Post my findings when I get home this evening. Thanks Phil

    Phil Balderos

    Tuesday, September 17, 2013 10:11 PM
  • That looks really strange, more like your extractor opened an MSI.

    What happens if you manually run the setup? Can you grab the extracted files from %temp%?


    Jason | http://blog.configmgrftw.com


    Hi Jason, I followed your advice and manually launched the program but at the same time I had the temp folder open in on my other screen and shire enough I found the MSI. Thus far I tested the install from a command Line and the install worked. The final test will be if I can run the same Command line from the SCCM package / program. I could not test last night as I was busy with good ok patch Tuesday. Ill post my findings this afternoon when I rebuild the package. Thanks for your help!

    Phil Balderos

    Wednesday, September 18, 2013 1:03 PM
  • That looks really strange, more like your extractor opened an MSI.

    What happens if you manually run the setup? Can you grab the extracted files from %temp%?


    Jason | http://blog.configmgrftw.com


    Hi Jason, I ran the program and watched the temp folder and nothing as far as MSI. I did how ever search for the msi and it pointed to the programs (86) folder. I found the MSI there and was able to package and deploy it in silent mode to four test computers. Thanks for your help Phil

    Phil Balderos

    Thursday, September 19, 2013 11:30 AM
  • Maybe it will help someone. SCCM 2016.

    In my case there was the same error (1619) in AppEnforce log, but It was not because of permissions. 

    The thing was in free space on locad Disk C: , there were just about 1 Gb free and it was not enough to install the application. So I cleared temp files in Windows and Appdata directories and after that I rerun the deployment in sccm. It was finished successfully.

    It was weird, because the error 1619 is definitly about permissions, as I read on other forums. And I had all the chances to stuck with this, but the same deployment has installed successfully on other computer, so i desided to check the free space on the problem client. 


    • Edited by ParaDancer Thursday, March 30, 2017 8:22 AM
    Thursday, March 30, 2017 8:16 AM
  • "because the error 1619 is definitly about permissions"

    No, that's incorrect. 1619 simply means the file can't be accessed for some reason outside the purview or visibility of the Windows Installer. The file simply not existing is a more common cause of this. In the case of a disk space shortage, its possible that the a self-extracting wrapper failed to actually extract the file and thus it couldn't be found.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, March 30, 2017 1:26 PM
    Moderator
  • Thanks for the insight.  I had this issue with a scripted install.  Using the log I was able to see where the install extracted the .msi
    Wednesday, May 16, 2018 3:34 PM