none
SCCM 2012 Deploying a MSI and MSP file together

    Question

  • Hello all,

        I'm trying to deploy an MSI and an MSP together as an Application in SCCM 2012. They are both in the same direct directory. They both are copied to the workstation.

    On the "Programs" tab of the "Deployment Types" I've set the "Installation program" to the following

    msiexec.exe /lvx* c:\Logs\ext.log /i "\\CAS\sources\Apps\TestPatch\TestInstall 1.msi" PATCH="\\CAS\sources\Apps\TestPatch\TestPatch 2.msp" \qn

    This fails in SCCM with a 0x87D01106 error. If I put it in the batch file, it works perfectly.

    I've also tried msiexec.exe /lvx* c:\Logs\ext.log /i "%~dp0eTestInstall 1.msi" PATCH="%~dp0eTestPatch 2.msp" \qn

    Which also works in a batch file.

    I've also tried msiexec.exe /lvx* c:\Logs\ext.log /i "TestInstall 1.msi" PATCH="TestPatch 2.msp" \qn

    Which also works in a batch file.

    If I put this in the "Installation program"  msiexec.exe /lvx* c:\Logs\ext.log /i "TestInstall 1.msi" \qn without the Patch information then the application is deployed correctly.

    Is there something I'm missing with deploying an application with a MSP?

    .


    • Edited by SJesseS Wednesday, November 07, 2012 7:14 PM
    Wednesday, November 07, 2012 7:13 PM

Answers

  • A few comments first.

    - Running something from a UNC using ConfigMgr makes almost no sense and is not scalable. Permissions must be set correctly on the UNC also (share and NTFS) to allow computers accounts access (assuming the program is set to run with admin privileges).

    - %~dp0 is only valid from within a batch file because its a batch file parameter.

    - MSPs specified with the PATCH property must be fully qualified.

    Thus, the only way to do this is using msiexec.exe /lvx* c:\Logs\ext.log /i "%~dp0TestInstall 1.msi" PATCH="%~dp0TestPatch 2.msp" \qn in a batch file.

    Is there some reason you are looking for alternatives?

    Applications in 2012 don't have to be MSIs; batch files, exes, ps1s all work fine.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by SJesseS Thursday, November 08, 2012 1:54 PM
    Thursday, November 08, 2012 12:53 AM

All replies

  • try with a relative path to your patch, so eg:

    msiexec.exe /lvx* c:\Logs\ext.log /i "\\CAS\sources\Apps\TestPatch\TestInstall 1.msi" PATCH="TestPatch 2.msp" \qn

    Wednesday, November 07, 2012 9:33 PM
  • I did... I've tried all of these..

    msiexec.exe /lvx* c:\Logs\ext.log /i "\\CAS\sources\Apps\TestPatch\TestInstall 1.msi" PATCH="\\CAS\sources\Apps\TestPatch\TestPatch 2.msp" \qn

    msiexec.exe /lvx* c:\Logs\ext.log /i "TestInstall 1.msi" PATCH="\\CAS\sources\Apps\TestPatch\TestPatch 2.msp" \qn

    msiexec.exe /lvx* c:\Logs\ext.log /i "\\CAS\sources\Apps\TestPatch\TestInstall 1.msi" PATCH="TestPatch 2.msp" \qn

    msiexec.exe /lvx* c:\Logs\ext.log /i "\\CAS\sources\Apps\TestPatch\TestInstall 1.msi" PATCH="%~dp0eTestPatch 2.msp" \qn

    msiexec.exe /lvx* c:\Logs\ext.log /i "%~dp0eTestInstall 1.msi" PATCH="\\CAS\sources\Apps\TestPatch\TestPatch 2.msp" \qn

    I was thinking along the same lines too.

    Wednesday, November 07, 2012 10:41 PM
  • A few comments first.

    - Running something from a UNC using ConfigMgr makes almost no sense and is not scalable. Permissions must be set correctly on the UNC also (share and NTFS) to allow computers accounts access (assuming the program is set to run with admin privileges).

    - %~dp0 is only valid from within a batch file because its a batch file parameter.

    - MSPs specified with the PATCH property must be fully qualified.

    Thus, the only way to do this is using msiexec.exe /lvx* c:\Logs\ext.log /i "%~dp0TestInstall 1.msi" PATCH="%~dp0TestPatch 2.msp" \qn in a batch file.

    Is there some reason you are looking for alternatives?

    Applications in 2012 don't have to be MSIs; batch files, exes, ps1s all work fine.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by SJesseS Thursday, November 08, 2012 1:54 PM
    Thursday, November 08, 2012 12:53 AM
  • I don't disagree with any of that.. You're absolutely right. But that's not the point. I was just saying that I through the kitchen sink at it. Providing the paths directly to the MSI and MSP file while obviously not practical point out that the issue isn't the command. It is being run as an admin but that is irrelevant, the install doesn't require admin permissions and the share is wide open. That command could be run by a user from the desktop and it works.

    I know that PATCH parameter requires the fully qualified path In that case this should work "msiexec.exe /lvx* c:\Logs\ext.log /i "TestInstall 1.msi" PATCH="\\CAS\sources\Apps\TestPatch\TestPatch 2.msp" \qn"

    But so should this "msiexec.exe /lvx* c:\Logs\ext.log /i "TestInstall 1.msi" PATCH="C:\Windows\ccscache\1\TestPatch 2.msp" \qn"

    or this "msiexec.exe /i "C:\Windows\ccscache\1\TestInstall 1.msi" PATCH="C:\Windows\ccscache\1\TestPatch 2.msp" \qn"

    or this is really the one that should work "msiexec.exe /i "TestInstall 1.msi" PATCH="C:\Windows\ccscache\1\TestPatch 2.msp" \qn"

    The files are downloaded by the deployment to the local cache. 

    However none work if the PATCH parameter is added. 

    I could certainty add it a batch file. But I wanted to know if it was possible to deploy a MSI and a MSP file together set in the "Installation program". Hence the question on the forum.

    So, have you done this?

    Thursday, November 08, 2012 2:05 AM
  • Running with admin privileges is very relevant because that means the process is launched as the local System which in turn uses the computer's AD account for authorization to network resources. AD computer accounts are not part of domain users and thus are not normally given permissions to access network shares or the NTFS permissions for the folders and files behind them. This is only relevant to running or referencing files from a UNC thus the reason I mentioned it in my bullet discussing UNCs.

    The question you posed in your last post was not explicitly or implicitly stated anywhere in your first two posts; however, I did answer it in my post: yes if you use UNCs to properly accessible network locations.


    Jason | http://blog.configmgrftw.com

    Thursday, November 08, 2012 4:53 AM
  • I know your question is "can I run both MSI & MSP together" and Jason has answered that but checking if you've thought about just patching your MSI?
    Thursday, November 08, 2012 6:55 AM
  • You're right Jason, and thank you. It is very relevant. I forgot that setting to run as Admin launches the as the System Account on the local workstation. I didn't have the computer's AD account authorization for any network resources. A critical mistake when accessing UNCs. I did add the computer account and It still fails to run once this is done.

    Also, setting the PATCH path to local cache location where the MSP was downloaded by the Software Center also fails. Which should work with or without network access.

    But you answered my question. You can, which means that there is a problem with my configuration. And not just the typos in the commands above. :) \qn isn't a right. Should have been typed /qn and the default cache location which is of course spelled "ccmcache". Both are correct on my actual SCCM server.

    @ Mick, thanks. It isn’t that I couldn't make it work using some other means. I was just trying to get the PATCH parameter to work in the command. I know it's a bad idea to actually use it. And your suggestion of patching the MSI would prevent the need for trying to deploy the MSI and MSP file together.

    I just wanted to know if it was possible.

    Thursday, November 08, 2012 1:53 PM
  • One more note: You shouldn't directly reference things in the cache either because that path is variable and unpredictable.


    Jason | http://blog.configmgrftw.com

    Friday, November 09, 2012 2:32 AM
  • Dear Jason,

    I have .msi application which I need to deploy through a Batch file using SCCM

    I have a shared folder, which contains the .msi file as well as the batch file.

    I create "Script Install" package through sccm. The client receives the package in CCMCache folder (Myapp as well the Batch file) and then the installation fails.

    The parameters in the batch file is....

    msiexec.exe /i "%~dp0MyAppSetup.msi" /qn

    I have even tried this

    msiexec.exe /lvx* c:\Logs\ext.log /i "%~dp0MyAppSetup.msi" /qn

    But if I copy the folder locally and run the Batch file locally it installs the software. Not sure what is missing.

    Please assist.


    Lewis

    Monday, July 01, 2013 9:31 AM
  • I have a shared folder, which contains the .msi file as well as the batch file.
    [...]
    I create "Script Install" package through sccm. The client receives the package in CCMCache folder (Myapp as well the Batch file) and then the installation fails.
    Using a shared folder does not make much sense. Why not using a DP instead?
    Which error code?

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, July 01, 2013 9:54 AM
  • Thanks for your reply Torsten...

    I have a Distribution point and the package is downloaded from the DP to clients CCM Cache folder.

    Error:

    The software change returned error code 0x64C(1612)

    Cheers !


    Lewis

    Monday, July 01, 2013 10:26 AM
  • 1612 =  The installation source for this product is not available. Verify that the source exists and that you can access it.
    Is MyAppSetup.msi located in the same folder as the batch file?



    Torsten Meringer | http://www.mssccmfaq.de

    Monday, July 01, 2013 10:34 AM
  • Yes it is.

    I can see myapp as well as the batch file downloaded to Client CCMcache folder.


    Lewis


    Any Idea Torsten, I Can share the .msi for testing.
    • Edited by Lewis vinod Sunday, July 07, 2013 4:44 PM Additional input
    Monday, July 01, 2013 10:37 AM
  • Dear Torsten,

    So far we have tested the deployment through GPO and it works.

    Good to have it deployed through SCCM, as all the methods are failing through SCCM.

    If you could share your email, I can share the .msi with you for your testing. Please let me know.

    Cheers !


    Lewis

    Tuesday, July 16, 2013 4:35 PM
  • Hello, we had similar issues with deploying some MSI/MSP applications. Not all, but some MSPs didn't like relative paths. Like you we tried variants of the command line with no success and while a simple script got the job done, there seems to be some apprehansion around scripts in use here, so we went another route...

    We setup 2 applications - one MSI and one MSP - and use dependency logic. We deploy the MSP which has a dependency (auto install) to the MSI. Works pretty well for us.

    GL!

    Tuesday, July 16, 2013 4:58 PM
  • Thank you for you reply.

    Just to shed more light on our .MSI.

    The application is build in Visual Studio and it is an “Add in” application.

    The “Add in” part is build in application name Add Express for Office and .Net Standard.

    This application will be the sub module of visual studio to give you more option to create “add in” applications.

    The application must be install as admin otherwise it will not update Registry and .DLL files.

    Basically it is a Single .MSI file


    Lewis

    Tuesday, July 16, 2013 5:07 PM
  • Hello, we had similar issues with deploying some MSI/MSP applications. Not all, but some MSPs didn't like relative paths. Like you we tried variants of the command line with no success and while a simple script got the job done, there seems to be some apprehansion around scripts in use here, so we went another route...

    We setup 2 applications - one MSI and one MSP - and use dependency logic. We deploy the MSP which has a dependency (auto install) to the MSI. Works pretty well for us.

    GL!

    First, this is accurate; it makes difference how the MSP was built. MSPs are applied by Windows Installer (msiexec) and the limitation of relative paths is a Windows Installer limitation when specifying the PATCH property.

    Next, my post near the top discusses using the PATCH property and and calling msiexec from within a batch file so that you can use the %~dp0 batch file parameter and thus specify a fully-qualified path.

    If you need more insight into why your MSI is failing then you need to add logging parameters to your msiexec command-line, namely /l*v.

    Finally, if installing as System or with admin permissions in ConfigMgr, it uses the local SYSTEM account to run the command-line. Given that your MSI is installing an add-in, it may have user dependencies that are not fulfilled by the SYSTEM account.


    Jason | http://blog.configmgrftw.com

    Tuesday, July 16, 2013 5:42 PM
  • Thank you Jason.

    One interesting point you have mentioned is about the Local System Account, I have a feeling that is the area that I have to look at.

    Noticeable: This is out of SCCM

    If I keep the package on a network share and run the package using a local admin credentials it installs correctly.

    Can I make this package run with a "Local Admin" credentials, instead of "Local System" through SCCM.

    Cheers !


    Lewis

    Tuesday, July 16, 2013 5:51 PM
  • No, not directly.

    To simulate the install as local System though, you can launch it with psexec and the -s option.


    Jason | http://blog.configmgrftw.com

    Tuesday, July 16, 2013 6:37 PM
  • Thanks Jason

    Will test and update...

    Cheers !


    Lewis

    Tuesday, July 16, 2013 7:02 PM