Application Repackaging: In corporate settings one often resorts to application repackaging to deal with legacy setup.exe
setups, and this is usually exactly because of their problematic
behavior in silent installation scenarios. I describe this process
here:
How to monitor and log manual installation
(section "Capture / Repackaging").
Technical Details: At a technical level Application Repackaging is shockingly simple in its approach. It involves scanning the system
before install and after the install and then capture the changes,
clean out a lot of junk settings and wrap the finished, new installer
in an MSI package (or some other format). Despite the technical
simplicity, the quality of such packages depend a lot on the knowledge
of its creator. Badly packaged MSI files can be loose cannons.
Package Format: Application Repackaging can be done in various formats, but the established MSI format (Windows Installer) has
a number of benefits for corporate use centering around reliable silent running and reliable remote management - arguably the
most important aspects of corporate deployment. Please see this answer
for some more details:
How to create windows installer.
Once you have an MSI you install it silently using standard
msiexec.exe command lines.
Tools: Commercial tools Advanced Installer and Installshield are the most well-known repackaging tools. They are
quite pricey. Sometimes people pay deployment consultants to do the
single package they have to convert. Very advisable in terms of the
knowledge needed to succeed as well. List of repackaging tools from
installsite.org.
Technical Limitations: Repackaging has limitations. Localization (support for different language versions) is one problem area - you capture the English version, so where are the
German files for the German version? That kind of stuff. These issues
are always different from setup to setup. It is reverse engineering to
be honest. Also, dynamically generated content that is
machine and user specific such as license keys, certificates, database connection strings with machine names and similar means you
might have to do a lot of work to get things to operate correctly, and
sometimes it is even technically impossible. It is a black art, but
when done right MSI files of excellent quality results that deploy
silently without much drama.
(Re)Packaging Team: Many corporations have whole teams dedicated to capturing and preparing legacy and modern setups for large scale
deployment. Many of them are offshore and unknown to most employees. I
would check if your company has such a team.
Logging?: What does the log files say? Is this a legacy setup.exe installer or does it install an MSI file under the hood? I would also check the system's event log for any clues - especially if you don't have a good log file. There should be a default Setup.log file created in the same directory and with the same name (except for the extension) as the response file.
The /f2 parameter can be used to specify a different log path:
setup.exe /s /f2"C:\Setup.log"
Here is a Flexera article on the subject of silent installation: https://resources.flexera.com/web/pdf/archive/silent_installs.pdf
And the most common silent install with logging command line:
setup.exe /s /f1"C:\sample\uninstall.iss" /f2"C:\sample\uninstall.log"
Response Files: The honest truth is that silent response files have never been reliable to achieve silent running. What often happens is that a special dialog pops up that was never recorded in the response file run, and then it all falls apart. This can be a "low disk space" warning or some other form of unexpected, random dialog that nobody predicted could show up.
Unexpected Dialog: Accordingly there could indeed be something different showing up when you install as domain users that are members of the admin group, although I can't really think of anything in particular that springs to mind as a likely candidate. I suppose the issue could also be one of privilege and access nonetheless. There could be certain NT privileges that are denied accounts in the standard user list for example. All just theories, I would go for the logging to get something concrete to start with.
Installshield Help File:
There are several relevant sections in the Installshield help file.
Please study these if you need more tweaking of the installation parameters. All switches are documented here - these links are for
the 2018 edition of Installshield:
Some Links: