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.