SCCM: Software Distribution Fails with Error Code 1603 in Execmgr.log

Error code 1603 by definition is just a generic windows installer (MSIexec) fatal error code. Yesterday I was seeing this for a software package deployment. The interesting part of this was this was an application that was packaged for us by a third party vendor (a vendor that will remain nameless, but has created some poor packages for us in the past that allows me to write up blog posts like this explaining the solution to their packaging issues), and the application was actually installing on some machines but not all. In total, about 50% had successfully installed the application and the other 50% had failed. So it was a very peculiar push that piqued my interest.

After looking at the advertisement report, I noticed that most of the successful installs were from Windows 7 machines. The failures were coming from Windows XP. So that pointed me to setup a test XP machine and test the push on that platform.

Next I looked at the package and how it was created in SCCM (I personally didn't set this up or work with the vendor on packaging it, so this was all new to me). I noticed that the install program was using a transform that the vendor had created as well as a requiring ISScript8 be run first before installing.

After doing some research, I came across a forum post that made reference to DCOM InstallShield InstallDriver Identity properties being set incorrectly. In my case, we were running this application with administrative rights and silently via SCCM. When a local administrator was logged on during runtime, the application would install fine. It would also install fine if no one was logged on. However if a user was logged on without admin rights, we'd get the 1603 error.

So I took a look at the InstallShield InstallDriver Properties from DCOMCNFG. To do this, follow the following steps:

From a command line (or start - run) type in dcomcnfg
Select Component Services
Expand Computers
Expand My Computer
Expand DCOM Config
Right click on InstallShield InstallDriver (in my case I had two of these)
Select Properties
Select the Identity tab

What SHOULD be selected here is The launching User. What I had selected was The interactive user. So by changing both InstallShield InstallDriver identities to The Launching User I was able to run the application successfully as the user which was a low rights account.

How to change the Installshield Installdriver Identity via VBScript

So I had the problem solved, but I needed a way to do this programatically. I basically needed to run ISScript first, then run a VBScript to change the Identity value, then run the application. The good news is that these options are all stored in the registry! The problem though is that they're stored in GUID/AppID format, and with different versions of ISScript out there, there isn't a consistent method to fix this. What this means for you is that you need to get the GUID/AppID yourself, luckily for you, you can get the GUID/AppID from within DCOMCNFG.

How to find the GUID/AppID from DCOMCNFG

To find the Application ID, repeat the steps I listed above to get to the Installshield InstallDriver Properties pane.

From a command line (or start - run) type in dcomcnfg
Select Component Services
Expand Computers
Expand My Computer
Expand DCOM Config
Right click on InstallShield InstallDriver (in my case I had two of these)
Select Properties
Under the General tab select the Application ID

Once you have the application ID, you can use the following VBScript to change the Identity of the Installshield InstallDriver. Note that if you only have one InstallDriver, you can remove the second path and the second deletevalue command.

const HKEY_CLASSES_ROOT = &H80000000
strComputer = "."

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
strComputer & "\root\default:StdRegProv")

strKeyPath1 = "Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}"
strKeyPath2 = "Appid\{INSERT APPLICATION ID HERE IN BETWEEN THE BRACKETS}"
strStringValueName = "RunAs"

oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath1,strStringValueName
oReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath2,strStringValueName

Once you've made the file, put it in the packagesource folder and make a new SCCM program using cscript nameofscript.vbs.

Comments

  1. Alan Kaplan says:

    I have extended your script to automate discovery of the AppID, and permit local or remote fixes. See, http://www.akaplan.com/blog/?p=618

  2. Brian Kilbourne says:

    This sounds like the same problem I am having. The installer has a prerequisite of isscript1150, so i have my program set to always run isscript1150.msi before the actual msi (client.msi) i'm trying to push. On my test machine i can install the program from command line using msiexec.exe /i client.msi /qn and it works perfect. isscript1150 is installing trough sccm but client.msi will not and returns a 1603 code. I've tried changing the identity to user launch on all instances of installshield on my sccm server and also the test machine i'nm trying to push to and still having no luck. Any help is appreciated.

  3. Akin Smith says:

    Many thanks for this article, Richard. I'd been struggling to deploy ISScript11.msi as a dependency to a main app via SCCM 2012 to a corporate Windows 7 build that already had ISScript versions 7, 8, 9, and 10.5. Initially, the version 11 wouldn't even install interactively, unless I MsiZapped the product code of the previous versions (they all had the same).

    Building a new MSI to deliver the data in ISScript11.msi allowed the script engine to be installed both interactively, and deployed from SCCM; but my main app still wouldn't install - ISStartup was still returning 3.

    After testing by altering the setting in dcomcnfg, I realized that simply removing the components iDriver.exe_Interactive_Key_NT4 & iDriver.exe_Interactive_Key from my new MSI would solve the problem. It did. Thanks again.

Speak Your Mind

*