Software Deployment

Do you need this for a specific installation?
The ISScript.MSI will be extracted to the %temp% folder when the setup.exe is launched so you should find it there if this is the case.
Did a quick search on the InstallShield site but no reference was found.

Newbie here.

I was looking for isscript12.msi also, since previous Appdeploy (and other) references have indicated how to use the isscript*.msi's to solve the issue of a vendor msi requiring setup.exe to start installation. In an attempt to repackage Trimble Pathfinder Office 4.0, I've run the setup.exe but *no* .msi's show up in %TEMP%. However, a folder is created there that holds setup.exe, setup.inx, _isres.dll, _isuser.dll, _ISRT.dll. Since the corresponding setup.ini file contains these lines:

ScriptDriven=1
ScriptVer=12.0.0.58849

I assumed that InstallShield script version 12 is involved.

Researching the Install Shield User Guide for version 12, http://www.macrovision.com/downloads/products/installshield/installshield/documentation/is12sp1UserGuide.pdf :

I found the following in Chapter 3, pg 39 (and more...):

"Run-Time Behavior for Basic MSI Installations with InstallScript Custom Actions For InstallShield 12 Projects

The following steps outline the run-time behavior for Basic MSI installations that include InstallScript custom actions:
1. The package is launched by the Windows Installer service.
2. Any sequenced InstallScript custom actions execute as follows.
a. Windows Installer calls the relevant entry point in ISSetup.dll (loaded from the Binary table).
b. ISSetup.dll extracts its Setup.inx resource to a temporary location.
c. ISSetup.dll executes relevant script code.
d. Windows Installer unloads ISSetup.dll.

The run-time behavior for InstallShield 12 Basic MSI projects that have InstallScript custom actions is much different than the behavior for InstallShield 11.5 and earlier because of some architecture enhancements. For more information about the
enhancements, see Upgrading Projects from InstallShield 11.5 or Earlier. ...."

Leads me to believe I have a lot more work to do to figure out why the GPS Pathfinder Office.msi 'requires' it to be run via setup.exe.

Any clues would be appreciated. I will continue to work on this and if I find a solution, will post. Thank you. -cb

cb, are you sure it uses the isscript12.msi?
The setup.inx file indicates that it does not use the ISScriptX.msi but instead uses the legacy engine.
What does a verbose log tell you?

Thank you for the response. Actually, at this point I'm certain this install doesn't use or require any isscript .msi since InstallShield 12 is involved.

So... I'm not sure how to proceed as the GPS Pathfinder Office.msi does display the "This installation cannot be run by directly lauching the MSI package. You must run setup.exe" message.

I found information (linked below) on how to deal with these issues by using Admin Studio, but have not figured out if it's possible using WPS.

http://support.installshield.com/kb/view.asp?articleid=Q112115

http://support.installshield.com/kb/view.asp?articleid=Q108166

I'll check the Altiris kb for more information, which I'll share if I find anything. Also, I'll take a couple more whacks at getting the .msi in question 'unwrapped' using ORCA and WPS. If I succeed, I'll post back. -cb

P.S.: Just found this post by you, AngelD, on Altiris KB:

"......Remove the files and the registry.
What I do but does take some time (maybe scripting it would be better) is to find any HKCR\TypeLib\{GUID} entry referring to "C:\Program Files\Common Files\InstallShield" and note down the GUID (SubKey) under the TypeLib key. Any HKCR\Interface\{GUID}\TypeLib (Default) referring to the TypeLib GUID (HKCR\TypeLib\{GUID}) can be removed.

So deleting the HKCR\TypeLib\{GUID} registry key which referred to the directory above and any HKCR\Interface\{GUID} registry key that had the TypeLib GUID from HKCR\TypeLib\{GUID} should do it.

Under Interface they often refer to as ISetupCopyFiles, ISetupCABFiles, IMsiServer, ISetupObjects and so on.

Scripting removal of these registries shouldn't be that hard. "

I'll try this. Thanks! -cb

Sounds like the basic ISScript fix, but I wonder if this will work for non-isscript.msi based setups.
Basically you have to add the ISSETUPDRIVEN property with a value of 1.
Remove or set the condition to false (1=0) for the OnCheckSilentInstall and ISVerifyScriptingRuntime custom actions.
You can find this info at http://www.appdeploy.com/messageboards/fb.asp?m=19850