The software change returned error code 1603

Troubleshooting application installations in SCCM 2012 R2 can seem daunting but it really isn’t. You just need to know where to look. A common error a lot of folks receive is “The software change returned error code 1603” and also “Process terminated with exit code 1603“. The first indication of a problem can be found in the Software Center of the client in question. When you open the System Center Configuration Manager 2012 Software Center and attempt to install the application it fails with a generic error “Unable to make changes to your software” or “The software change returned error code 0x643(1603)“. Of course the error code will be different depending on the issue. The first question you MUST answer is whether the software package in question is failing to install on ALL or just some clients. Chances are that if the package is failing to install on ALL your clients, then something is most likely wrong with the installation package. This may not always be true but the probability is high that it is. However, if the package is being successfully deployed and installed on many clients but failing on others, then use the steps below to troubleshoot why SCCM is failing to install your application successfully.

SCCM has a ton of logs, sometimes I think they may have too many! Depending on what you are troubleshooting, will determine what logs you should be reviewing. In this blog post, we are troubleshooting application installation failures. There are two main logs that I use when troubleshooting application failures; Execmgr.log and AppEnforce.log. The SCCM client logs can be found in the following directory of each client’s local hard drive; c:\Windows\CCM\Logs\. The following Technet site has everything you need to know about the purpose of every SCCM log file and what it contains. If you want to be an expert on troubleshooting SCCM issues, check out https://technet.microsoft.com/en-us/library/hh427342.aspx.

The Execmgr.log contains detailed information regarding the installation packages that run on all SCCM clients. Sometimes the information in this log may not make sense or get you going in the wrong direction if you are not careful. In the example below, note the error “Failed to open WMI namespace“. When you perform a Google search on this error, you’ll notice several articles regarding WMI corruption. However, in this example, that was NOT my problem. I only bring this up to point out that it is important to investigate multiple logs to try and piece together your particular scenario. Sometimes the Execmgr.log might have some useful information so I think it is worth always looking at. At the very least, I know there is something that SCCM doesn’t like about this particular package trying to install on this particular client.

The AppEnforce.log contains very detailed information about the Install or Uninstall of the package. This is where you notice specific error codes regarding the installation of your software package. In the example below highlighted in Yellow, this package failed to install on my client and recorded error, “Unmatched exit code (1603) is considered an execution failure“. We already know that the SCCM package is fine but for some reason it is unable to successfully install on this client. Further down in the log, it will give you the exact installation file and all its parameters. In the example below, we can see the command is “AdobeSetup.msi /q /qn” highlighted in Green. A few lines down, note the location of the MSI (C:\Windows\ccmcache\sr).

One way to troubleshoot why this package isn’t installing is to log onto the client computer that is experiencing the problem and navigate to the location of the MSI (C:\Windows\ccmcache\sr) and run the AdobeSetup.msi command without the /q parameter so that you can see why the application is failing. When I did this, on the client computer, I found that this particular client was missing a specific version of the .Net framework. So I installed the .Net framework it needed and let SCCM retry the installation of the package and it worked.

Of course there are other ways to tackle this problem. One thing that you should probably always do is when building the SCCM package, is to set the logging flag and log the installation details so that all you need to do is open that log file and view the results. I’ll leave that for another time.

Hope this helped someone. If so, be sociable and leave a comment! Thank you.