Scripting Question

*.iss response file gives a dialogue box at the end.

06/24/2014 2381 views
Hello Everyone

I am silently installing an application using the setup.iss file. The entire installation works fine but in the end, it presents a dialogue box saying the installation was complete. How can I suppress that box?

I used setup.exe -r to record the installation and then setup.exe -s -f1 setup.iss to play the recording. both the files are in the same folder to f1 is not even required. I have tried the installation with and without it and it works even without f1 but I am still getting the dialogue both in the end saying the installation is complete and it waits for an input from the user to press enter.

I have tried sending an enter key using a script but since the window is waiting for a user input, the send enter key script is never triggered.

Has anyone ever had this issue and was able to fix it?

SOLUTION: I captured the application separately to create a single MSI and installed and it and installed the drivers using a Custom Action.
0 Comments   [ + ] Show comments


All Answers


It does rather sound like the final dialog originates elsewhere to the other dialogs, and if so, no amount of recording will capture your final response.

I've encountered this before and sometimes had to resort to using AutoIt to respond to the prompt.

Here's a few lines of AutoIT script which might get you started if you go down that route

winwait("Zone Labs TrueVector service","This is a security",240)
Winactivate("Zone Labs TrueVector service","This is a security")


  • The script waits for a Window with the title "Zone Labs TrueVector service" and containing text beginning "This is a security"
  • When detected, the script gives the Window focus
  • The script then send Alt+Y to the window, which in this case equates to a click of the "Yes" button.
  • There is a timeout of up to 240 seconds for the window to appear before the script will terminate anyway

Just modify the values in the script to meet your own particular needs.


Answered 06/24/2014 by: spartacus
Black Belt

  • Sorry but I don't like using AutoIT scripts. I'ts not packaging.
    • I will tell you how to get around with it by capturing that application using Wise or Installshield packager and you will have no problems with that dialog. Using AutoIT is still a part of packaging because your aim is to deliver that software without a user intervention. Most of the time, if you are not capturing the application, AutoIT or any scripts will help you achieve that and have a package.
      • Capturing drivers is not recommended otherwise I would have captured the installation to get around the issue. I thought I will check with everyone here first to see if there is a argument I can pass in the *.iss that will suppress that dialogue box. If not, instead of capturing, I will try to extract the drivers and install them using dpinst.exe.

"I have tried sending an enter key using a script but since the window is waiting for a user input, the send enter key script is never triggered."

"Sorry but I don't like using AutoIT scripts. I'ts not packaging".

Now I am confused, which type of script have you tried using and why did that one qualify as "packaging" whereas AutoIT does not, in your view ?


Answered 06/25/2014 by: spartacus
Black Belt

  • I used VBScript which is widely used in packaging. For instance, for creating custom actions and even for wrapping MSIs for deployment depending on the environment.

    AutoIT script is a third party "tool" that uses keystrokes and screen coordinates to automate the installation and IF the mouse is moved or the keys are touched during the process, your "package" will break. How many users can you stop from doing that?
I, too, dislike using tools like AutoIT: it's a horrendous kludge in my view.

Save yourself a whole heap of trouble and just repackage the app. The AppDeploy...sorry, IT Ninja... Repackager does the job, if your employer is too cheap to purchase a proper packaging tool.

FWIW, I almost never use vendor's installation set-up executables. I want to know EXACTLY what their EXE is going to do to my workstations!
Answered 06/26/2014 by: VBScab
Red Belt

  • My employers preference is avoid capturing applications and to use the vendor media therefore I was trying to get the vendor media to work but I couldn't. I posted the solution in my question.
    • Great job! And now, even better, your employer knows that you know more about packaging than they do. I was going to comment that it's part of your role as the packaging "expert" to educate your employer. Dictats that make no sense - like letting vendors loose on your workstation estate (Adobe Acrobat Pro v9.01, anybody? Ha, ha, ha!) - are a huge mistake and *will* get you bitten on the arse! And then to whom do you think the blame will be attributed? "You're the expert! You're meant to know about this stuff!"
      • Don't you think I did? We can only advise but it's up to them to implement and they want to keep things the way they are.

If the native install is an MSI, can you not disable the final dialog with a transform?

If it is an EXE, how about running the exe from a wrapper, and then killing the installation process once the end is reached?

Answered 07/02/2014 by: EdT
Red Belt

  • Tried that from a wrapper but because the dialogue box is launched, the process is stuck there and the line that's supposed to close the box is never executed. Anyways, it's done now.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ