Converting a InstallShield setup into an msi
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?
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
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
turbokitty
15 years ago
http://itninja.com/question/msi-corporate-standardiser6&mpage=1䶊
Posted by:
JeanM
15 years ago
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.
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.
Posted by:
turbokitty
15 years ago
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.
Posted by:
WayneB
15 years ago
Jean,
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.
Regards
Wayne
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.
Regards
Wayne
Posted by:
anonymous_9363
15 years ago
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]'
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]'
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.