none
SCCM And MSI Return Codes

    Question

  • I have an application that calls an msi which writes a log. The application successfully installs as stated in the log which I posted below. However it returns a code of 1641 which simply means a reboot is needed (http://support.microsoft.com/kb/290158). SCCM state messages are reporting the deployment status as error with description 1073807364. A line shows up in execmgr.log which also shows this - "Script for Package:CPS0009F, Program: Install failed with exit code 1073807364". And in Software Center the status is "Failed". Question is, will SCCM consider any code other than 0 that is passed by the MSI as an install failure?

    Here is the install log:

    2014/12/29 07:56:34:648::[20076] Successfully installed package: LyncWW path:C:\MSOCache\All Users\{90150000-012C-0000-0000-0000000FF1CE}-C\LyncWW.msi
    2014/12/29 07:56:34:648::[20076] 12/29/2014 07:56:34 Committing MSI transaction.
    2014/12/29 07:56:53:681::[20076] 12/29/2014 07:56:34 MSI transaction committed.
    2014/12/29 07:56:53:681::[20076] Unable to commit a system restore point.
    2014/12/29 07:56:53:681::[20076] Not showing completion dialog because it was not requested.
    2014/12/29 07:56:53:681::[20076] Reboot requested always automatically.  Attempting to initiate reboot.
    2014/12/29 07:56:53:687::[20076] Catalyst execution finished: 12/29/2014 07:56:53.  Return code: 1641.


    • Edited by Matt MS Monday, December 29, 2014 3:17 PM none
    Monday, December 29, 2014 3:16 PM

Answers

All replies

  • In general, yes, nearly all codes besides 0 are treated as a failure. There are a few that are not though and I thought a 1641 was among those.

    Have you reviewed execmgr.log on the client to verify that's what is actually being returned to the ConfigMgr agent?

    1073807364 does not equal 1641 so there's something else going on here.

    Your program name says "Script" which implies that you are running a script and not just msiexec. Thus, what else is in your script after msiexec is called? Whatever it is is what is failing and that return code is what is being passed back to ConfigMgr.


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

    Monday, December 29, 2014 4:11 PM
  • Yes it is a batch file which runs setup.exe and this calls the msi to install Lync 2013. The contents of the batch file are below:

    "%~dp0x86\setup.exe" /config "%~dp0x86\lync.ww\config.xml"

    SCCM is interpreting the return code 1641 as 1073807364 although nowhere in the installer log can I find 1073807364. It is saying failed for the status although it installed successfully but just needs a reboot.

    Monday, December 29, 2014 4:29 PM
  • Doing some research it looks like this is a wrapper issue where the wrapper may be returning control before the install completes successfully. See below for some examples.

    http://www.symantec.com/business/support/index?page=content&id=TECH170504

    http://stackoverflow.com/questions/4192773/sometimes-msi-exited-with-code-1073807364

    http://boincfaq.mundayweb.com/index.php?view=296&language=1

    Check your Lync install log for any failures, they may not be at the bottom of the log. CMtrace may be able to help find them quickly.


    Daniel Ratliff | http://www.PotentEngineer.com

    Monday, December 29, 2014 4:53 PM
  • Concur with Daniel. 1641 is the return code from msiexec but you are not using msiexec, it is being called by setup.exe. Thus, the return code from msiexec is irrelevant here. The return code from setup.exe is what is important to ConfigMgr and that won't be in the msi install file because its not part of the msi. Please check execmgr.log to verify.

    1073807364 = 40010004 (hex). The actual error code here is thus 4 which means "The system cannot open the file" -- 4001 is the facility code. Not sure what that means in this context. You should check the actual office setup log which should be in the temp folder of the system: http://support.microsoft.com/kb/826511

    Why are you using a batch file for this though?

    x86\setup.exe" /config x86\lync.ww\config.xml

    would work perfectly fine as the program's command-line. There's no need to use %~dp0 here as the program's execution will already be from the correct directory and the parameter path can be relative: http://blog.configmgrftw.com/current-directory-in-configmgr-programs/

    Also, why not use an application for this?


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

    Monday, December 29, 2014 5:06 PM
  • Jason,

    Thanks again for your help. I have redirected the setup log using the config.xml file. (Microsoft Office Lync Setup(20141229075440512C).txt) to another folder and that is what has the 1641 in it. The "Script for Package:CPS0009F, Program: Install failed with exit code 1073807364" is the only error line in execmgr.log. So not sure how to track down anything else or why it interprets 1641 as 1073807364. Both the line with return code 1641 and the error line in execmgr.log with 1073807364 were written at the same time.

    Using a batch file because there are a couple other lines in there that write registry keys that's all.

    We target most deployments to collections of computers not users and they are required deployments as well so what are the advantages of deploying by application vs package? I know one of them is that they are state based so if a user uninstalls the application it will automatically reinstall. Also, is it true that application which is required and deployed to a computer will still only show in Software Center not Application Catalog.


    • Edited by Matt MS Monday, December 29, 2014 6:11 PM none
    Monday, December 29, 2014 6:09 PM
  • And what does that "setup log" tell then? execmgr.log is irrelvant for now.

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

    Monday, December 29, 2014 6:12 PM
    Moderator
  • Given that you actually have a couple of additionally lines in your batch file (which is why I was asking about what's in the batch file), they could actually be are failing with the error code of 1073807364 instead of setup.exe. Have you tried with just the command-line I mentioned to isolate the source of the error code?

    As for applications, not at all. They are equally applicable for users and devices. Applications add a lifecycle management factor that revolves around the detection method. There are other advantages also and none are specific to users or devices.


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

    Monday, December 29, 2014 6:16 PM
  • Torsten,

    The setup log has the following lines in it:

    2014/12/29 07:56:34:648::[20076] Successfully installed package: LyncWW path:C:\MSOCache\All Users\{90150000-012C-0000-0000-0000000FF1CE}-C\LyncWW.msi
    2014/12/29 07:56:34:648::[20076] 12/29/2014 07:56:34 Committing MSI transaction.
    2014/12/29 07:56:53:681::[20076] 12/29/2014 07:56:34 MSI transaction committed.
    2014/12/29 07:56:53:681::[20076] Unable to commit a system restore point.
    2014/12/29 07:56:53:681::[20076] Not showing completion dialog because it was not requested.
    2014/12/29 07:56:53:681::[20076] Reboot requested always automatically.  Attempting to initiate reboot.
    2014/12/29 07:56:53:687::[20076] Catalyst execution finished: 12/29/2014 07:56:53.  Return code: 1641

    When I lookup return code 1641 it means a reboot is needed.

    http://support.microsoft.com/kb/290158

    Monday, December 29, 2014 7:50 PM
  • Ok I tried that and it still gives me the same error code 1073807364. I believe it is getting this from the 1641 return code which is in the setup log. The other two lines in the batch file were just using taskkill and regedit.

    Monday, December 29, 2014 7:53 PM
  • That's not correct. As mentioned, the msi is what is returning 1641, not setup.exe. There's something else that setup.exe is doing besides calling the msi that is causing the error and thus setup.exe is returning the error code. This is clear from execmgr.log where you reported that it shows 1073807364 and not 1641.

    Which log file exactly is the snippet above from?

    Also, here's a blog post that describes where deployments show up (it has nothing to do with it being an application or package): http://blogs.technet.com/b/configmgrteam/archive/2012/03/31/introducing-the-application-catalog-and-software-center-in-system-center-2012-configuration-manager.aspx


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

    Monday, December 29, 2014 8:03 PM
  • The snippet is from the setup log - Microsoft Office Lync Setup(20141229075440512C).txt. Unfortunately I don't see anything else in this log that points to an error besides the above snippet.

    I thought it does have to do with whether it is an application or package that determines where it will appear (Software Center or Application Catalog)?

    Monday, December 29, 2014 8:37 PM
  • I thought it does have to do with whether it is an application or package that determines where it will appear (Software Center or Application Catalog)?

    No, not at all. Please see the blog post I linked to above.

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

    Monday, December 29, 2014 8:42 PM
  • Just a thought here, Is outlook open on the PC you are sending this out to? If it is, try closing that out and see if it still asks for the reboot.. I am not sure of the scope you are looking at but it may be a quick option if it is a limited test..

    • Edited by acamizzi Monday, December 29, 2014 8:45 PM
    Monday, December 29, 2014 8:44 PM
  • the difference in which location is not the package, it is how you deploy it. If you send it to a device collection it will go to Software Center. User collection will be Application Catalog.
    Monday, December 29, 2014 8:47 PM
  • Yes Outlook is open. We were forcing a restart as a means to close/reopen Outlook automatically. I know I could just do a script that closes Outlook only before the install runs but just decided to restart instead. I don't believe the actual application requires a restart all the time as when I set to restart if needed (AutoIfNeeded) it usually doesn't but still requires the user to close and reopen Outlook so that the plug-in appears.

    Wednesday, December 31, 2014 1:05 PM
  • Oh right I meant that the resources in the targeted collection is what causes it to appear in either. So I guess you can't deploy an available package to a collection of users unless you've already enabled the application catalog?
    • Edited by Matt MS Wednesday, December 31, 2014 1:12 PM none
    Wednesday, December 31, 2014 1:12 PM
  • You can, they just cannot see it. You can only see required deployments in Software Center when targeting users.

    Daniel Ratliff | http://www.PotentEngineer.com

    Wednesday, December 31, 2014 1:17 PM