Scripting

For all Installshield setup, it is better to create .iss file as a response file which will capture all your inputs and will store in it. You will have to create a install.iss and uninstall.iss for silent installation and uninstallation.

you can get some idea of iss file creation from here:

http://support.microsoft.com/kb/922143

This is not a dig against InstallShield, but rather on how it can be used and abused...

Flexera has built an incredibly flexible product.  It's possible to build a Setup.exe that is entirely self-contained and installs the application.  It's possible to build a Setup.exe that unpacks another Setup.exe and uses that one to do the installation.  It's possible to build  Setup.exe that unpacks a second Setup.exe, which in turn unpacks an MSI and uses that to do the install.  And there are probably dozens of other ways it can be sliced and diced.  This makes repackaging an InstallShield created installer a bit of a pain for administrators, since every variation uses a different command line scheme to install silently.

Depending on exactly how that Setup.exe was constructed, your options for automating it vary considerably. 

The moderators can delete this post if the link is inappropriate, but I wrote up a fairly lengthy document about the different variations you commonly see with InstallShield and how to make them "silent", here:  http://wdasite.com/2012/12/installshield-for-adminstratorspart-1/

The short version is that if the MSI installs the product, and the product is functional, but the product's missing some settings, I might do the following...

I'd go ahead and install the product with the MSI.  Then I'd start a setup capture using whatever tool you use (AppDeploy Repackager, Wise Package Studio, AdminStudio, etc.).  Let it do the "before" scan.  Launch the application.  Make the necessary settings changes in the software's preferences.  Close the application.  Finish the setup capture and identify what files and registry keys changed when you adjusted the application's settings.  Add these to an MST, and deploy the MSI and MST together.  This should get you a configured application.

Another option is to open the MSI and then look in the Property table.  Sometimes there are properties that correspond to the settings you're looking for, especially if the user interface in the Setup.exe asks for those settings.  For instance, you might see a Property called SERVER or PORT.  Adding the correct value for these properties in an MST would allow you to silently install the application and pre-configure it.

Yet another option would be to use setup.exe along with those property values, as in:

setup.exe /s /v /qn SERVER=myserver PORT=123

In this case, the "/s" is telling Setup.exe to be silent, the "/v" tells it to pass the rest of the command line on to MSIEXEC.EXE.  Thus, it would install the MSI using "/qn" (i.e., be completely silent) and supply the value for the SERVER and PORT properties.

I have a script (which I unfortunately cannot share because I don't own it) in VBScript that you can launch in the background while running an installer to see what processes it launches and what command line it uses to do that.  I use that script with frustrating installers to see if it's passing any command line arguments to another SETUP.EXE or to the MSIEXEC.EXE program.  Often this uncovers the property names that the setup.exe is passing to the MSI.

Hopefully this helps some.