none
Package install keeps failing with exit code 1619

    שאלה

  • 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

    יום שלישי 17 ספטמבר 2013 18:53

תשובות

  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 19 ספטמבר 2013 11:27
    יום שלישי 17 ספטמבר 2013 20:54
    מנחה דיון
  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 24 מרץ 2016 15:12
    יום שלישי 17 ספטמבר 2013 19:49
  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 24 מרץ 2016 15:12
    יום שלישי 17 ספטמבר 2013 21:51
    מנחה דיון

כל התגובות

  • Hi Do you run the package from a dp or do you download it to the client and run from the cache?
    יום שלישי 17 ספטמבר 2013 19:14
  • 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

    יום שלישי 17 ספטמבר 2013 19:28
  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 24 מרץ 2016 15:12
    יום שלישי 17 ספטמבר 2013 19:49
  • 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

    יום שלישי 17 ספטמבר 2013 20:45
  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 19 ספטמבר 2013 11:27
    יום שלישי 17 ספטמבר 2013 20:54
    מנחה דיון
  • 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

    יום שלישי 17 ספטמבר 2013 21:28
  • 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

    • סומן כתשובה על-ידי Phil Balderos יום חמישי 24 מרץ 2016 15:12
    יום שלישי 17 ספטמבר 2013 21:51
    מנחה דיון
  • 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

    יום שלישי 17 ספטמבר 2013 22:11
  • 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

    יום רביעי 18 ספטמבר 2013 13:03
  • 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

    יום חמישי 19 ספטמבר 2013 11:30
  • 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. 


    • נערך על-ידי ParaDancer יום חמישי 30 מרץ 2017 08:22
    יום חמישי 30 מרץ 2017 08:16
  • "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

    יום חמישי 30 מרץ 2017 13:26
    מנחה דיון
  • 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
    יום רביעי 16 מאי 2018 15:34