How to deploy the Installshield MSI without having to run Setup.exe

Article:HOWTO4204  |  Created: 2006-07-10  |  Updated: 2011-04-05  |  Article URL http://www.symantec.com/docs/HOWTO4204
Article Type
How To




Question
 

My Installshield based vendor MSI will not install unless I run setup.exe. I want to install the MSI directly. How can I do this?

Answer
 

The Installshield file setup.exe launches a file called isscript.msi that, in turn, installs the InstallScript engine required to run InstallScript code. This article discusses how to install an Installshield vendor MSI without using setup.exe.

To deploy a script-driven MSI using Active Directory (or another deployment method that requires the MSI format), you must configure the setup and the target system in the following manner:

Install ISScriptx.msi (where x denotes the version with which the setup was authored). At the time of writing, there are several versions of  ISScript.msi; major versions 7, 8, 9, and 10, with attendant minor versions for each major release. The property table of the MSI will often specify the required version of ISScript.msi and it is important to have the correct version for your application, otherwise it may not run. Different versions of ISScript.msi appear to co-exist on target computers.

The ISScriptx.msi is located in the same folder as the MSI package and must be deployed on the target computer prior to the MSI. This installs the InstallScript engine required by the MSI package during deployment.

Using an MSI editor, make the following modifications to the MSI, either directly or via a transform:

  • Add the property ISSETUPDRIVEN to the property table and give it a value of 1.
  • Add a condition to the "OnCheckSilentInstall" custom action in the InstallExecuteSequence that always resolves to False or remove the custom action from the sequence.
  • Make any additional changes required, such as populating the serial number, modifying shortcuts or feature states.

Note that the method described above does not solve 100 percent of all cases. In some cases, the MSI file contains no internal dialogs, and instead the setup.exe file handles user dialogs by interacting with custom actions in the MSI. These custom actions will fail if setup.exe is not running. There is no simple solution to this.

However, there are known custom actions to remove from MSI files exhibiting this behavior. Removing these custom actions will give you a much greater chance of successfully freeing the MSI from its dependency on setup.exe

The custom actions are:

  • ISVerifyScriptingRuntime
  • ISStartup
  • OnCheckSilentInstall
  • OnGeneratingMSIScript
  • OnMoving
  • OnFeaturesInstalling
  • OnInstallFilesActionBefore
  • OnInstallFilesActionAfter
  • OnFeaturesInstalled
  • OnMoved
  • OnGeneratedMSIScript
  • ISRebootPatchHandler

Exercise caution in removing more than the listed actions as you could inadvertently remove a custom action that is required to install or configure parts of the application.

Deploying the MSI package

If deploying the package via Active Directory, make sure that you set the Installation User Interface to Basic and remember to specify any transforms that you made for the MSI package.

If deploying via SMS, the following information may be relevant:

ISScript.msi contains DCOM objects; these DCOM objects do not allow SMS to have access to them. Therefore when you run the main MSI which has ISScript.msi as a prerequisite, the main MSI does not have permissions to access ISScript.msi.. (If you logged the ISScript install you would probably see a 1603 error.)

If you want to manually fix this you will need to edit the registry and change a setting on the DCOM object.

To explore this further, install your version of isscript.msi manually on your test workstation. Then run up DCOMCNFG and look for Installshield items. You should find a couple of entries. Select properties then goto identity. Then toggle a user permission which SMS doesn't have access to the middle option of launching user.

The toggle sets a registry entry and this Wise macro will implement these changes in the ISscript file automatically. Enter this in to the macro editor. Open the ISScript and run it. It will add some CAs that remove the associated reg keys.

Sub subISScriptFixup
'insert your code here

For Each rowInstallExecuteSequence In tblInstallExecuteSequence.WRows

If rowInstallExecuteSequence("Action") = "InstallFinalize" Then

IntSequence = cInt(rowInstallExecuteSequence("Sequence"))

Exit For
End If

Next

subCreateCustomAction "IAGISScriptFix8","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{E4A51076-BCD3-11D4-AB7D-00B0D02332EB} /v AuthenticationLevel /f"
subCreateCustomAction "IAGISScriptFix7","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{E4A51076-BCD3-11D4-AB7D-00B0D02332EB} /v RunAs /f"
subCreateCustomAction "IAGISScriptFix6","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{C2B96968-8E30-4BA4-A8F9-F40D09D1EA7E} /v AuthenticationLevel /f"
subCreateCustomAction "IAGISScriptFix5","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{C2B96968-8E30-4BA4-A8F9-F40D09D1EA7E} /v RunAs /f"
subCreateCustomAction "IAGISScriptFix4","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{99BDE2B6-D79E-11D4-AB87-00B0D02332EB} /v AuthenticationLevel /f"
subCreateCustomAction "IAGISScriptFix3","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{99BDE2B6-D79E-11D4-AB87-00B0D02332EB} /v RunAs /f"
subCreateCustomAction "IAGISScriptFix2","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{1BB3D82F-9803-4d29-B232-1F2F14E52A2E} /v AuthenticationLevel /f"
subCreateCustomAction "IAGISScriptFix","3170","WindowsFolder","CMD /c REG DELETE HKCR\AppID\{1BB3D82F-9803-4d29-B232-1F2F14E52A2E} /v RunAs /f"

subCreateInstallSequence "IAGISScriptFix8","",cstr(IntSequence - 8)
subCreateInstallSequence "IAGISScriptFix7","",cstr(IntSequence - 7)
subCreateInstallSequence "IAGISScriptFix6","",cstr(IntSequence - 6)
subCreateInstallSequence "IAGISScriptFix5","",cstr(IntSequence - 5)
subCreateInstallSequence "IAGISScriptFix4","",cstr(IntSequence - 4)
subCreateInstallSequence "IAGISScriptFix3","",cstr(IntSequence - 3)
subCreateInstallSequence "IAGISScriptFix2","",cstr(IntSequence - 2)
subCreateInstallSequence "IAGISScriptFix1","",cstr(IntSequence - 1)

rowInstallExecuteSequence = Nothing
IntSequence = Nothing

End Sub

Several different versions of ISScript have been investigated for this problem, from major versions 7, 8, and 9.

There appear to be three possible DCOM objects that ISScript.msi installs:

  1. One called "Installshield Installdriver" configured for "Interactive User"
  2. One called "Installshield Installdriver" configured for "Launching User"
  3. One called "Installshield Installdriver String Table" configured for "Launching User"

Here is what was found (figures in brackets are the first 3 digits of the object GUID):

Versions 7.2.0.221, 7.4.0.337 and 7.7.0.262 installed a.(E4A) and c.(99B)
Version 8.0.0.123 installed only a. (1BB)
Version 8.1.0.304 installed a.(1BB) and b.(C2B)
Versions 9.0.0.333 and 9.1.0.429 installed a.(933) b.(A24) and c.(346)

It is believed that the versions which install b will work okay with SMS, which means that version 7 definitely needs fixing and also early version 8.

It is peculiar that neither version 8 appears to install a string table object, whereas both version 7 and 9 do. Testing was carried out on an XP SP2 VMware virtual machine,  reverting back to a clean build after each install, to avoid cross contamination by the different ISScript.msi files.

This information is offered without guarantees, and it is up to the individual to verify the information within their own testing environment.


Legacy ID



24566


Article URL http://www.symantec.com/docs/HOWTO4204


Terms of use for this information are found in Legal Notices