Hello all,

I'm trying to create an unattended installation and it appears that the main bulk of the configuration details are held in a file called setup.isn.

I can't find much information regarding this file anywhere and wondered if anyone has some good links/advice or even a tool so I can take a look at the contents of this file?

Thanks

Ed
0 Comments   [ + ] Show Comments

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.

Answers

0
For anyone else who wants to know what setup.isn is/does it appears to be just a way of making a pretty skin for a "manual" installation...not really what we are alll interested in on this site....

The customisation for the app I'm working with is actually carried out by another file called "setup.ini" which judging by the info I can find on AppDeploy can be a pain to work with...have contacted the vendor for more info
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
0
Heck, just capture it to an MSI and have done with the faffing about.
Answered 06/24/2010 by: VBScab
Red Belt

Please log in to comment
0
whats the name of the application

is it one of those monster apps that cannot be packaged (msi)
Answered 06/24/2010 by: cygan
Fifth Degree Brown Belt

Please log in to comment
0
Huh? An app which CANNOT be packaged? Is there such a thing? Certainly there have been apps which I wish I hadn't packaged and some which I haven't bothered to package but never encountered one which couldn't be.
Answered 06/24/2010 by: VBScab
Red Belt

Please log in to comment
0
Thanks for the interest in my issue everyone,

The app consists of Setup.exe which calls IIScript11.msi on launch and then prompts the user for the "pre-reqs" they should install prior to the installation of the "actual" application required (called GE Centricity XI 3.10)

It also registers some .dlls later on in the installation process and it actually shows a regsvr32 prompt twice (!) this is surely really easy for the vendor to suppress?

The vendor, to their credit, has been able to dig out a silent installation command which goes like:

setup.exe /z"--CLTYPE=TERM1"

Which appears to suppress any prompts for user interaction but does not suppress the registration of the .dll files message from regsvr32

VB (or anyone else) do you reckon I should try to repackage the entire installation as 1 .msi....is this even possible considering the setup.exe wrapper that does carry out additional configuration of which I only have evidence of the regsvr32 prompts ...in otherwords setup.exe/setup.ini could in theory do much more than I know about...
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
0
The /z switch just passes argument(s) to the CMDLINE variable for the installshield setup.
If you fail to create a response file for the installation (and uninstall) and it's not an MSI already (extracted during install) then just re-capture it to an MSI.

Best shot for the dll registration; find the extracted MSI and fix the stupid custom action or repackage it
Answered 06/24/2010 by: AngelD
Red Belt

Please log in to comment
0
Huh? An app which CANNOT be packaged? Is there such a thing?

hence that's why I asked the QUESTION
Answered 06/24/2010 by: cygan
Fifth Degree Brown Belt

Please log in to comment
0
well it is already an msi so re-packaging could be a problem - along with the fact that I will have to use free tools.

I already attempted to create transforms for the app yesterday but as I cant guarentee what is happening via the wrapper and setup.ini made no real progress....just attempting to repackage using the free repackager from AppDep now
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
0
If the stub is extracting and executing an MSI, abandon the re-packaging. You should never re-package MSIs.

As for any activity that the stub might be undertaking outside the MSI, this is where your adherence to Best Practise comes into play. That is, once you have an MSI, you should produce a gap capture between it and the stub. Remember to rename the registry Uninstall entry, to avoid being prompted to Repair/Modify/Remove. Then you incorporate all relevant changes into your MSI (if you have captured your own MSI) or into your transform (if the MSI is vendor-supplied).

At the end of the exercise, you have the added bonus of being able to offer the vendor a properly constructed installer for an extortionate price.
Answered 06/24/2010 by: VBScab
Red Belt

Please log in to comment
0
VBScab: the .msis are already extracted (the stub doesn't carry out any extraction but it does execute the IIScript installation (no prompts) followed by the vendor msi) so guess a re-package is possibly out of the question.

I would really love to polish this particular turd for the vendor but get the feeling that I wont have enough time to learn how to carry out a "gap capture" - but will of course Google/research for information regarding this.

Get the feeling that I may have to return to faffing around with setup.ini to perhaps pass a command line argument to the vendor msi.....or rely on the techs to carry out the installation manually...
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
0
Actually a Gap Cap looks to be fairly easy to understand in principle....
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
0
I won't repeat it, as it'd be quicker for to search here. Search for 'InstallWatch' and you should pick up a bunch of responses from me, at least one of which will contain a step-by-step guide to taking a gap capture, although I only recently started referring to the exercise using that term.
Answered 06/24/2010 by: VBScab
Red Belt

Please log in to comment
0
thanks will take a look
Answered 06/24/2010 by: mosquat
Orange Belt

Please log in to comment
Answer this question or Comment on this question for clarity