I have a product called Arc Console Supervisor. I had a look on the software list here and there is an Arc Console product but not the supervisor.

It is an Installshield setup.exe file.

When I open it until the welcome screen stage, I go into the %temp% directory and there are two folders instead of one.

Also in the root of the %temp% directory there is a file named 1fc2.rra.

The two folders are shown below:


I have never seen two folders produced before.

Anyway, if I install the original arc supervisor setup.exe as above the file it works ok, but you need to fill in, Company name, server name, ip address etc.

When I use the MSI file it does not prompt for any information. The file just installs.

This is where I am confused.

I have tried a few different products and I presume I need to make a response transform.

Is this correct?

I just tried a product that allowed me to convert the original setup.exe file into an MSI file.

I then tried to make a response transform out of this new MSI file but it failed.

Please advise what I am doing wrong.

Be kind.









2 Comments   [ - ] Hide Comments


  • enable logging. In the generated log you will all the answers for your question
  • Yes, you're right. You need to create a response transform.

    What talonsprem87 is trying to tell you is that a verbose log will tell you the names of the properties which will be used to contain the server name. You can then set those properties in the transform. I suspect you may also need to add a property called ISSETUPDRIVEN with a value of '1', or you may be prompted that the installation must be run using the EXE.

    Also, remember that software vendors are generally pretty dumb and may include logic in the stub that should really go in to the MSI so, once you have your MSI and transform, perform a gap capture (using something like InstallWatch) to determine whether this one does or not.
Please log in to comment

Community Chosen Answer



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:


Answered 07/11/2013 by: piyushnasa
Red Belt

  • Cheers guys, I think the developer has done something very weird with this installshield setup.exe.

    How do you enable verbose logging with an Installshield setup.exe?

    I will try a gap capture as I have tried numerous ways now but just cannot get the MSI to work.

    If I go down the road of using an ISS file, I need to use the setup.exe though.

    I would like in our environment to only use MSI files due to set a standard and for the logging capabilities.

    Question, what do most people do these days, leave it and just install as an installshield setup or convert to an MSI?

    I should add we about to move to SCCM 2012 from Dell KACE.

    Would you still bother just using MSI files?


  • Standards are meant to give the best deliverable. If you cannot deliver something at its best with MSI and with an exe then the standards should be broken. What will you do in case of Adobe Creative Suite installations? You can't make one MSI for it.
    Anyways, what I wanted to say was, Al ot of MSI extracted from Installshield setup work fine and I have used them in the past, but once we tried to extract the msi from installshield setup and made it work exactly like the setup, but while uninstalling it, it removed a lot more stuff than it installed. Do a check on this..
Please log in to comment
Answer this question or Comment on this question for clarity



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.

Answered 07/17/2013 by: msalsbury
Second Degree Blue Belt

Please log in to comment