I am trying to convert a package that started off as an InstallShield setup.exe, it's a wrapper that runs the ISScript and then runs ReportViewer.msi located in the .exe

The setup.exe runs fine manually with -s and -uninst but fails when used in SCCM using System context for silent deployment. The MSI extracted from the setup.exe does not run on it's own, I figured out that if the ISScript.msi is installed first and ISSETUPDRIVEN=1 property is added to the ReportViewer.msi then it can be installed w/o the setup file (so far manually, have not tried yet using System context). So, using WPS 7.0 I then converted the ISScript.MSI into a .MSM file and added it to the ReportViewer.MSI as I am trying to make it into ONE stand alone MSI file that can be silently installed. When I "test" the MSI in WPS I get the "1: The InstallScript engine is missing from this machine." error. The ISScript.msm is listed under the Merge Modules, but obviously I am missing something.

Any tips or suggestions?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Answered 01/20/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
Thanks! Reading through it .. does anybody have an updated link to the InstallScript video that bkelly posted in the /video/ section?

I don't want to make a wrapper, trying to go away from it, so possibly I need to create a transform with the merge module that I have already included?

I guess it depends more on the type of MSI or MSM I am working with, in this case it's an ISScript and it's a required component before the other MSI of the application itself can be installed. AngelD talks about being able to use an MSM as it will change the sequence order so that the the msi install won't fail right upon execution...

"The "After" column for the "EngineStartup.4F635B62_07BF_4779_B74E_D80C29D508E3" CustomAction defines "Action to come before BaseAction" (0) defined by the "BaseAction" column which in this case is "ISMsiServerStartup". When the merge module has been merged into the msi the EngineStartup action will be inserted right before the ISMsiServerStartup action making sure to installer the required ISScript support before the ISMsiServerStartup action establishes the connection between the InstallScript engine and the Windows Installer engine.

Just make sure the ISMsiServerStartup action has the same sequence order in the msm as in the msi. "

I'll give the suggestions made in that thread a shot.
Answered 01/21/2009 by: JeanM
Senior Yellow Belt

Please log in to comment
AngelD is the Installscript MSM resident God. I haven't seen him post in awhile, but perhaps you'll get lucky. In the meantime, I'd encourage you to try out what he's documented.
Answered 01/21/2009 by: turbokitty
Sixth Degree Black Belt

Please log in to comment

Don't forget the folowing information from Kim's (AngelD) post:
"Remove the OnCheckSilentInstall custom action from the InstallExecuteSequence table to prevent the MSI from checking if a silent installation was performed without using Setup.exe. Remove the ISVerifyScriptingRuntime custom action from the InstallUISequence table to prevent the MSI from checking if the installation was launched using setup.exe during UI sequence."

I'd be inclined to condition these CA's with an impossible-to-meet condition (borrowed from VBScab) "0=1" or just comment them out. Easier to rollback if it doesn't work.

Answered 01/21/2009 by: WayneB
Blue Belt

Please log in to comment
Rather than trying to shoe-horn the IS engine/driver in as a MM, why not deploy it (and the other IS flavours) separately to every machine using SCCM? My own preference is for these to be in the build but it's probably too late for that in your case.

If you want to persist down that route, enable MSI Logging (verbosely) on your target collection. The resulting log will be in %SystemRoot%\TEMP, prefixed with 'MSI', named with random alphanumeric characters and with a .LOG extension. That makes it tricky to track which log belongs to which but I use FIND to do that. Remember that this is an all-or-nothing policy so you'll need to turn it off when you're done. Alternatively, if you're using a command line install in SCCM, you can add the verbose logging switch to it: '/L*V %SystemRoot%\temp\[whatever.log]'
Answered 01/22/2009 by: VBScab
Red Belt

Please log in to comment